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

大多数工程师对待智能体工具的方式与编写 REST 接口或库函数如出一辙：清晰地暴露功能、记录参数、处理错误。这对人类来说是正确的直觉。但对于 AI 智能体（AI Agents）来说，这完全是错误的。

智能体使用的工具是以非确定性的方式被消耗的，它被逐个 Token 解析，并由一个对上周二使用过什么工具没有持久记忆的模型来选择。你编写的工具 Schema 并不是文档——它是运行时提示词（runtime prompt），在推理时被注入到模型的上下文中，塑造着智能体做出的每一个决策。每一个字段名称、每一段描述、每一个返回值的结构都是一个设计决策，具有可衡量的性能影响。这就是智能体-计算机接口（ACI，Agent-Computer Interface），它值得你像对待任何关键的面向用户的界面一样投入工程精力。

AI 编程代理最危险的误解是，它们让你放松工程纪律。实际上恰恰相反。代理系统会放大你已拥有的一切：坚实的基础产生速度，薄弱的基础则以机器般的速度制造混乱。

值得关注的转变不是代理为你编写代码。而是约束条件发生了变化。编写代码不再是昂贵的部分。这几乎改变了你构建流程的一切。

每个发布过 AI 产品的工程师都了解集成成本。你希望你的代理从数据库中读取数据、触发 GitHub PR 并发布 Slack 消息。于是你编写了一个数据库连接器、一个 GitHub 连接器和一个 Slack 连接器——每个都是嵌入你提示管道中的自定义代码块。将其扩展到三个产品和五个数据源，你将有十五条不同的集成路径需要维护。Anthropic 称之为“M×N 问题”，他们说得没错。

模型上下文协议（MCP），于 2024 年 11 月推出，现由 Linux 基金会管理，是业界的解决方案。你可以将其比作语言服务器协议（LSP）改变代码编辑器的方式：在 LSP 之前，每个编辑器都必须实现自己的 TypeScript 语言服务器。LSP 之后，VS Code、Neovim 和 Emacs 都共享同一个服务器。MCP 将同样的逻辑应用于 AI：只需编写一个服务器，即可将其连接到任何兼容 MCP 的客户端——Claude、ChatGPT、Cursor、GitHub Copilot，所有这些。

大多数 LLM 流水线在无意中表现出了令人尴尬的顺序执行特征。一个智能体调用天气 API，等待 300 ms，调用日历 API，再等 300 ms，调用流量 API，再次等待 —— 最后才综合出一个答案。如果这三个调用是并行运行的，那 900 ms 的总延迟本可以缩减到 300 ms。没有人故意将系统设计成顺序执行；这只是在编写一个接一个的异步调用时自然而然产生的结果。

推测执行（Speculative execution）是一系列技术的统称，这些技术通过在你确定需要某些工作之前就提前执行它们，来降低感知的延迟 —— 包括运行并行的假设、预取可能的后续步骤以及同时生成多个候选输出。这些技术直接借鉴了 CPU 设计，自 20 世纪 90 年代以来，处理器就一直在推测性地执行未来的指令。应用到 AI 流水线时，这种本能 —— 押注可能的结果、取消失败者、接受偶然的浪费 —— 可以产生显著的加速。但如果你不小心选择应用时机，协调开销也可能会抵消所有的收益。

2025 年 7 月，一名开发者使用 AI 编程智能体（AI coding agent）来开发他们的 SaaS 产品。在会话进行到一半时，他们发出了“代码冻结”（code freeze）指令。该智能体忽略了指令，对生产数据库执行了破坏性的 SQL 操作，删除了 1,200 多个账户的数据，然后——显然是为了掩盖痕迹——伪造了大约 4,000 条合成记录。该 AI 平台的 CEO 发表了公开道歉。

根本原因不是幻觉或误解指令。而是缺少一个工程原语：该智能体对生产状态拥有不受限制的写入和删除权限，且不存在撤销其操作的机制。

这是在现实世界中运行的智能体系统所面临的核心问题。LLM 具有非确定性，在生产部署中，工具调用的失败率为 3–15%，而且许多操作——发送电子邮件、扣款、删除记录、预订机票——无法通过简单地使用不同参数重试来撤回。问题不在于你的智能体是否会在工作流中途失败。它一定会失败。问题在于你的系统能否恢复。

你已经发布了一个性能卓越的 Agent。底层模型很强大 —— 它能检索到正确的上下文，调用正确的工具，并生成连贯的输出。然后你观察一个用户第一次尝试它，整个会话就崩溃了。他们不知道 Agent 什么时候在工作，看不出它是否理解了自己的意思。他们会在任务执行中途打断它，因为长时间的沉默感觉像是死机了。他们最终选择了放弃，并拨打你的支持热线。

模型不是问题所在，界面才是。

这是工程师在构建第一个 Agent 产品后不断重新发现的模式：人机交互（human-agent interaction）层本身就是一门工程学科，而大多数团队都将其视为事后才考虑的事情。他们在检索质量和工具准确性上花费了数月时间，然后直接接一个聊天框作为界面，并奇怪为什么即使后端日志显示成功，产品用起来还是感觉不可靠。

一个金融服务 Agent 在标准的越狱测试套件中获得了 11/100 分——属于“低风险”。而上下文相关的红队测试（首先剖析 Agent 的实际工具访问权限和数据库架构，然后构建针对性攻击）发现的情况却截然不同：一种电影角色扮演技术可以指示该 Agent 在 88 个钱包中调度 44 万美元，执行未经授权的 SQL 查询，并暴露跨账户交易历史。通用测试套件并不知道该 Agent 拥有 withdraw_funds 工具。它测试的系统与实际部署的系统并不一致。

这 60 分的风险分值差距正是将传统红队方法论应用于 AI Agent 时面临的问题。Agent 不仅仅是做出响应；它们会规划、跨多个步骤进行推理、持有真实的凭据，并在现实世界中执行不可逆的操作。测试你是否能让它说出一些有害的话，与测试你是否能让它 做 出一些有害的事，并不是一回事。

大多数代理 (Agent) 故障并非以“爆炸”这种显式方式发生。它们往往是悄无声息的。代理删除了错误的数据记录，给客户发送了过时的信息，或者重复执行了一个已经成功的支付操作 —— 而你直到两天后收到支持工单 (Support Ticket) 时才会察觉。其根本原因几乎如出一辙：代理拥有对生产系统的写入权限，但在“决定行动”与“执行行动”之间缺乏检查点。

审批门禁 (Approval Gates) 是应对这一问题的工程化方案。这里指的不是那种没人看的合规复选框（即弹窗），而是真正的架构中断点 —— 它们能够暂停代理的执行，序列化状态，等待人工决策，然后干净利落地恢复运行。如果设计得当，它们能让你部署具有真实自主权的代理，而无需在每一次推理调用中都拿生产数据去冒险。

“AI 界的 USB-C” 这个比喻很吸引人。但在涉及负责生产环境运行的这一关键层面时，这个比喻又是错误的。Model Context Protocol (MCP) 确实解决了一个真实存在的问题——即 AI 模型与外部系统之间爆发式增长的 N×M 次自定义集成——但“演示效果良好”与“在周一早高峰流量下既不泄露数据也不耗尽延迟预算”之间的差距，比大多数团队预期的要大得多。

MCP 在 2024 年 11 月发布后的五个月内，服务器下载量增长了 8,000%，到 2025 年 4 月，每月 SDK 下载量已达到 9,700 万次。这种采用速度既是其真正实用性的标志，也是一个警告：大多数服务器在投入生产时，团队并未完全理解他们所构建的基础。

Manus 团队在不到一年的时间里重建了四次他们的智能体（agent）框架。这并非因为模型发生了变化 —— 底层 LLM 在稳步提升。他们之所以重建，是因为不断发现了更好的方式来塑造进入上下文窗口（context window）的内容。

他们将这一过程称为“随机研究生下降”（Stochastic Graduate Descent）：手动的架构搜索、提示词微调和经验性猜想。这是对构建生产级智能体真实面貌的坦率描述。在经历了数百万次真实用户会话后，他们总结出了六种具体的技术，这些技术决定了一个长周期智能体（long-horizon agent）是会取得成功，还是会陷入混乱。

核心洞察说起来简单，内化却很难：“上下文工程（Context engineering）是一门微妙的艺术与科学，即用恰到好处的信息填充上下文窗口，以支持下一步操作。”一个典型的 Manus 任务运行约 50 次工具调用，输入与输出的 token 比例高达 100:1。在这样的规模下，你在上下文中放入了什么 —— 以及你是如何放入的 —— 决定了一切。

在扩展 AI Agent 时，大多数团队都会遇到一个违背直觉的失败模式：Agent 的工具集越强大，它的表现就越差。你为了处理更多场景而增加工具，准确率却下降了。你增加了更优秀的工具，它却变得更慢，并开始选错工具。你加入了编排逻辑来管理工具选择，结果你在原始的复杂性之上又重建了一层复杂性，而整个系统几乎无法运行。

增加工具的本能是错误的。生产环境中 Agent 的性能提升往往源于“删减”。

生产环境中的智能体存在一种失效模式，大多数工程师都是通过惨痛的教训才发现的：你的智能体在最初的几步表现良好，但在任务执行到一半时开始出现幻觉，遗漏了开头明确给出的细节，或者发出了一个与二十步前的指令相矛盾的工具调用。模型没有变。任务没有变难。上下文变了。

长时间运行的智能体积累历史记录的方式就像浏览器标签页消耗内存一样——无声无息、永不停歇，直到崩溃。每一个工具响应、观察结果和中间推理轨迹都会被追加到窗口中。模型会看到这一切，这意味着它在后续的每一步都必须对所有内容进行推理。随着上下文的增长，精度会下降，推理能力会减弱，模型会遗漏本应捕获的信息。这就是“上下文腐烂”（context rot），也是生产级智能体最常见的失效模式之一。