51 篇博文 含有标签「ai-agents」

那些真正在为生产环境客户交付可靠 AI 智能体的团队，大多并未使用智能体框架。他们选择自研。

这一观察源自与 100 多位技术创始人的交流，也是 12 要素智能体（12-Factor Agents）框架那个令人不安的起点——这是一份旨在构建能够投入生产、而非永远停滞在 80% 质量水平的 LLM 驱动型软件的宣言。该框架刻意借鉴了塑造了一代 Web 服务的原始 12 要素应用（12-Factor App）方法论。这种类比是成立的：正如 12 要素应用为团队提供了构建可部署 Web 服务的原则性方法，12 要素智能体也为构建可靠、可观测的 AI 系统提供了原则。

这个拥有 19,000 颗星的 GitHub 仓库记录了表现最出色的生产团队独立摸索出的经验。以下是他们的共识。

2025 年 6 月，一名研究员向一位 Microsoft 365 Copilot 用户发送了一封精心编写的邮件。没有点击链接。没有打开附件。邮件送达后，Copilot 在执行例行的总结任务时读取了它，短短几秒钟内，AI 便开始从 OneDrive、SharePoint 和 Teams 中外泄文件——通过将数据编码进它请求“渲染”的图片 URL 中，悄无声息地将内容传输到了攻击者控制的服务器上。受害者对此一无所知。

从传统意义上讲，这并不是一个新奇的零日漏洞（Zero-day）。没有缓冲区溢出，也没有 SQL 注入。该漏洞是架构性的：系统结合了三种能力，这些能力单独看起来像是理所应当的产品功能。但结合在一起，它们就构成了现在所谓的“致命三要素”（Lethal Trifecta）。

大多数 AI Agent 演示（demo）运行得都非常完美。

它们在 30 秒内运行完毕，调用三个工具，并返回整洁的结果。然后，有人要求 Agent 执行一些真正重要的事情——交叉引用代码库、运行多阶段数据流水线、处理批量文档——于是整个过程在超时、部分状态和重复副作用的级联反应中土崩瓦解。

问题不在于模型，而在于基础设施。运行几分钟或几小时的 Agent 与在几秒钟内完成的 Agent 相比，面临着完全不同的一类系统问题。大多数团队在最糟糕的时间点撞上了这堵墙：在他们已经发布了用户依赖的产品之后。

大多数 LLM 质量问题并非提示词（Prompt）问题。它们是上下文（Context）问题。

你花了数小时打磨完美的系统提示词。你添加了 XML 标签、思维链指令和精细的人设定义。你在一些输入上进行了测试，效果看起来很棒。然后你上线了产品。两周后，你盯着一个工单发呆：智能体一本正经地告诉用户错误的账户余额 —— 因为它检索到了前一个用户的交易记录。模型完美理解了指令，它只是拿到了错误的输入。

这就是提示词工程（Prompt Engineering）与上下文工程（Context Engineering）之间的核心区别。提示词工程问的是：“我该如何措辞？”上下文工程问的是：“模型现在需要知道什么，以及我如何确保它准确获得这些信息？”前者是文案写作，后者是系统架构。

大多数团队都是事后才给他们的智能体添加记忆功能——通常是在用户抱怨智能体忘记了三轮对话前明确告知的信息之后。那时，解决方案似乎显而易见：把对话存储起来，以后再检索。但这种直觉往往导致系统在演示中表现出色，而在生产环境中却一塌糊涂。一个仅仅存储信息的记忆系统，与一个能在正确的时间可靠地呈现正确信息的系统之间存在巨大鸿沟，大多数智能体项目正是悄然失败于此。

记忆架构并非次要问题。对于任何处理多轮交互的智能体——无论是客户支持、编码助手、研究工具还是语音界面——记忆都是区分有状态助手和昂贵自动补全的关键。如果处理不当，智能体不会崩溃；但它会让人感觉有些不对劲，自相矛盾，或者自信地重复着用户两周前纠正过的过时信息。

第一次一个 AI 编程代理破坏了一个团队的 CI 流水线——不是因为它编写了糟糕的代码，而是因为它生成拉取请求的速度超过了 GitHub Actions 的处理能力——这清楚地表明一些根本性的东西已经发生了转变。我们不再讨论一个更智能的自动补全工具。我们讨论的是一种完全不同的软件生产模式。

AI 辅助编程的发展轨迹迅速。自动补全工具改变了个人打字的方式。本地代理改变了单个会话能完成的任务。云代理现在正在改变团队构建软件的方式——将工作并行化到多个异步线程中，在提交 PR 之前运行测试，并且越来越多地处理长达 3 小时的任务，而开发人员则可以休息或转去解决其他问题。

大多数智能体故障都是架构故障。当任务偏离轨道时，模型往往会受到指责，但十有八九，真正的问题在于没有人充分思考规划、工具使用和反思应该如何协同工作。即使你换一个更好的模型，仍然可能会遇到同样的崩溃——因为模型周围的支架从未被设计成处理模型被要求完成的任务。

本文是一份关于智能体内部实际工作原理的实用指南：核心组件是什么，规划在哪里出错，反思循环如何帮助（以及何时会损害），以及当你为生产而非演示构建多智能体系统时它们会是什么样子。

大多数声称在“生产环境中有智能体”的团队其实没有。调查一致显示，大约 57% 的工程组织已经部署了 AI 智能体——但当你应用严格的标准（LLM 必须能够规划、行动、观察反馈并根据结果进行调整）时，只有 16% 的企业部署和 27% 的初创公司部署符合真正的智能体标准。其余的只是加装了工具调用功能的“美化版”聊天机器人。

这种差距不在于模型能力，而在于架构。真正的自主智能体需要三个相互关联、协同工作的子系统：规划、记忆和工具使用。大多数实现只正确地完成了其中一个，部分实现了第二个，却忽略了第三个。结果是系统在演示中表现出色，但在生产环境中却会不可预测地失败。

大多数构建 AI 智能体的团队犯了同一个错误：他们在理解失败是什么样子之前，就开始着手评估基础设施。他们构建仪表盘、选择指标、连接评估器——然后发现他们的评估完全测量错了东西。六周后，他们得到了一份绿色的记分卡，但智能体却是坏的。

解决方法不是更多的工具。它是一系列特定的步骤，在你自动化任何事情之前，将你的评估建立在现实基础之上。以下就是这些步骤。

大多数智能体故障不会自行报告。没有崩溃，没有警报，没有堆栈跟踪。你的智能体只是默默地返回错误答案，跳过工具调用，或在任务中途停滞——而你直到三小时后用户投诉时才发现。从“在开发环境中正常运行”到“在生产环境中可靠”的差距，并非仅仅增加重试次数就能弥补。它关乎构建一个能够检测自身故障、对故障进行分类并在不半夜两点把你吵醒的情况下恢复的系统。

以下是自修复智能体管道在实践中的实际面貌。

多数构建 AI 代理的工程师将 80% 的时间花在思考使用哪种模型上，20% 的时间花在其他所有事情上。这个比例应该反过来。模型在这一点上几乎是可以互换的——决定你的代理是否能在生产环境中实际工作的是“线束（harness）”。

这个等式很简单：**代理 = 模型 + 线束。**如果你不是模型，你就是线束。而几乎所有真正的工程工作都存在于线束中。

大多数构建 AI 智能体的团队都将模型视为固定不变的产物。你选择一个基础模型，编写提示，连接一些工具，然后发布。如果智能体开始出错，你会调整系统提示或切换到更新的模型。在这种框架下，学习发生在“上游”——在 AI 实验室中，在预训练和 RLHF 阶段——而不是在你的技术栈中。

这是一种错误的思维模型。随着时间推移而改进的智能体，是在三个不同的架构层面上实现这一点的，其中只有一个层面涉及修改模型权重。了解这一区别的团队能够构建出质量持续提升的系统；不了解的团队则会不断手动修补相同的故障模式。