AI笔记
第一部分（个人理解）：从chantGPT问世开始：在2024年，一款爆火的智能问答软件出现，就是chatGPT，他的出现代表了基于Transformer架构的LLM的作用开始发挥作用，也就是说在超大规模的参数训练下，Transformer下的LLM出现了质的突破，这个阶段的“AI”突破了过去的“假AI”，开始了真正意义上的人工智能，我们可以利用LLM实现自己的智能对话机器人，智能客服和智能文章生成，以及智能文章提炼总结，但是他的弊端也很明显，就是无法解决复杂业务场景下的复杂问题，更多的是大家在自嗨，但是不可否认的是 他开创了一个新时代。基于这个局限性，大家发现了一个新的架构模式，即RAG模式，既然LLM无法解决各个领域的专业性问题，那么就在LLM之上结合向量数据库Milvus实现垂直领域的专业AI工具，例如专业领域的智能客服等等，这样即没有破坏大模型本身的准确性，又实现了私域的扩展性，然后大家发现这一套模型也无法满足许多复杂业务的AI智能化需求，因此出现了多模态场景下的AI工具，其本质是将图片和视屏转化为多维向量，然后基于LLM实现快速理解多模态和生成多模态，这个阶段下，AI的可玩性和可用性就高了很多，大家可以让AI理解视频，然后按照自己的prompt让AI生成视频，所以这个能力可以运用到一些短视屏平台，或者宣传视频，或者电商平台的商品宣传图等场景，开始在多个领域帮助用户解决实际问题，例如gemini3。但是后来大家又发现 每一次使用AI的成本都很高，比如每一次都要从让AI理解和提示AI和让AI生成，最后再根据满意程度进行反复重试，其成本很高，而且流程无法服用，因此出现了新的架构模式，AI agent，agent作为针对某一个场景或者领域的解决方案而出现，他是一个工具也是一个代理，他可以基于langchain框架按照提前配置好的流程，进行多个步骤和复杂场景的自动化实现，比如客户仍然是一句话需求，但是agent可以根据需求进行分析，然后基于memory、tools、LLM和其他的一些组件进行搭配和流程化，最终得到用户想要的一个结果，一个agent在完成用户的需求的时候，可以解决几个问题：第一个是历史上下文，第二个是调用第三方服务，第三个是基于LLM的分析，进行合理的步骤执行，虽然agent做到了一个完整AI产品能力，但是他也带来了几个问题，一个是历史上下文过大，导致token过长，从而影响到了响应素速度和成本，二是调用第三方，如何保证服务高可用以及服务鉴权，基于这两个问题，后来出现了一些针对历史上下文做精简和过滤和关键信息提取的框架和工具例如Memori，优化了历史上下文token过长的问题，然后又出现了MCP协议，他为AI场景下 如何安全可靠的对外提供原子API能力和调用第三方API能力提供一套标准，这也是一种演化结果，前面这几个阶段基本上都是基于软件场景下的，那么在硬件场景下，出现了比较火的豆包手机和特斯拉智能驾驶，他们的核心能力就是基于GUI实时图像获取和分析，进行智能化决策和指导下一步操作，豆包用的是AUTOGLM模型，例如可以一句话让豆包手机帮助在淘宝下单等完整的智能化操作。最后就是近期比较火爆的agent skills，他本质不是一个算法 而是一个解决方案和工具的打包标准，可以将agent skills做一解决某一个场景和专业领域的工具，他本身可能是一个agent，也可能是多个mcp或者小型LLM的合计，然后利用MCP对外提供服务，到这个阶段 形成了多种垂直专业领域 + 水平叠加扩展的 这么一套AI架构。由于业内多种模型的出现，各个模型之间的差异化也逐渐体现出来，对于用户来说，高昂的学习成本是试错成本也在不断叠加，那么一个好用的平台化产品就至关重要了，因此出现了类似open router这种AI智能网关系统，OpenRouter AI智能网关是一个为解决“多模型调用混乱”而生的一站式AI模型聚合与路由平台。它的核心价值在于，让开发者或企业只需对接一个统一的API接口，就能灵活、经济地调用数百个来自不同供应商的AI模型。统一API：将OpenAI、Anthropic、Google等众多厂商各不相同的API接口，全部封装成标准的、与OpenAI兼容的格式，让你只需维护一套代码。智能路由：你可以设置预算、延迟偏好或规则。平台会根据你的设置，自动将请求分发到不同模型。例如，简单查询发给低成本模型，复杂任务则交给GPT-4或Claude等顶级模型。统一管理：在一个平台上管理所有模型的密钥、查看使用量、费用明细和调用日志，大大降低了运维成本。
- RAG的工程陷阱：RAG的检索精度、数据更新延迟、多路召回合并策略等都会影响最终效果。平台如何设计评估体系？
- Agent的调度复杂性：Agent的流程编排（如LangChain）常面临稳定性问题（LLM输出解析失败、工具调用异常）。平台是否需要引入状态机、回退机制？
- 硬件协同的架构挑战：豆包手机等端侧AI涉及模型轻量化、跨端云协同推理（如部分计算在手机NPU，部分在云端）。平台如何统一管理异构算力？
第二部分（个人实践）：我实现的场景是AI智能宝宝监控机器人，整体架构是多云架构：树莓派（主板和摄像头和话筒）+ 远程服务器（部署AI大模型和agent）+阿里云短信服务，首先树莓派我搭配了摄像头和话筒，对宝宝进行实时监控和画面捕捉和声音捕捉，然后将数据实时传给部署在树莓派主板的小参数LLM，进行分析，如果发现出现了异常情况则将异常信息（5秒钟之前到当下的图像和声音）发送给远端服务器agent，agent在接收到数据之后，将前后对比下的图片和声音发送给千问大模型API，进行二次确认和分析，拿到分析结果之后，根据返回选择告警方式，如果不严重 则只发送短信，如果严重 则直接利用虚拟号码 对提前配置的监控人进行电话智能外呼通知，直到告警接触。其中图像实时监控和抓取用的是openCV，部署的中心LLM是千问的7B模型，部署的边缘LLM是bitnet的2B模型，短信和外呼使用的是阿里云的付费服务，agent框架是基于java的langchain4j框架。
- “异常情况”的定义是什么？（如：哭泣、爬出围栏、长时间静止？）
- 如何训练或Prompt小LLM来减少误报？是否引入了基于规则的过滤器（如：声音分贝阈值+视觉运动检测）作为LLM的前置？
- 树莓派断网或重启后，数据如何补发？云端Agent服务挂掉，边缘端是否有本地兜底告警（如蜂鸣器）？
- 云端大模型API调用和电话外呼都是有成本的。如何避免因边缘误报导致的无效成本？
第三部分（归纳总结）：AI将向通用人工智能（AGI） 探索，但当下更清晰的方向是 “超级通用智能体”与“多智能体协作” 。这不仅能独立完成任务，更能像团队一样协同工作，处理涉及判断、协商和跨系统协调的复杂业务流程。
然而，在通往大规模应用的道路上，我们必须正视和解决以下关键问题，其中一些正以“悖论”形式显现：
- 生产力与成本悖论：引入AI初期可能导致生产力短期下降（“J型曲线”），且需要为保障可靠性增加隐性工作。同时，AI巨大的算力与能源消耗（数据中心用电激增）与降本增效的初衷形成矛盾。
- 能力与治理风险：AI能力越强，其可能产生的“模型幻觉”、决策错误、数据安全与隐私泄露的风险就越大。同时，技术滥用导致的虚假信息泛滥（“AI糟粕”），将挑战社会信任体系。
- 技术碎片化与地缘政治：全球AI技术生态存在割裂风险，加上激烈的地缘竞争，可能阻碍技术合作与全球治理框架的建立。
总的来说，未来AI的竞争力不仅取决于算法创新，更取决于能否将技术有效、可靠、负责任的工程化落地，并与能源、就业、伦理等社会系统取得平衡。