你的AI Agent技术栈在解决错误的问题

大家都在分享的搭建方案

安装哪些 MCP 服务器。仓库里保留哪些 skills。选哪个 agent 框架。怎么写你的 AGENTS.md。怎么把一个 agent 拆成 researcher、planner、coder、reviewer。怎么把 Slack、GitHub、Notion、Postgres、Stripe日历和文件系统串成一个越来越强的闭环。

其中有些建议是有用的。但它们针对的是错误的层级。

agent 使用工具之后真正产生什么后果，比它能不能调用工具重要得多。

它能读取客户记录，还是能修改？能起草退款单，还是能直接退款？能打开 Pull Request，还是能合并？能提出供应商回复，还是能以公司名义发送？

一旦 agent 能通过工具行动，真正的系统就不再是模型本身了。

真正的系统是围绕模型构建的契约栈。

这是大多数搭建指南跳过的那部分。

Access 是reach。Agency 是经授权的行动。

agent 能读 Slack。能搜邮件。能查 CRM。能开 GitHub Issue、查账单记录、浏览文档、编辑表格、起草客户回复，还能调用三个内部 API。

在场所有人都说这很强。

那是第一个误区。

agent 有 reach。但它还没有受治理的 agency。

Access 告诉你 agent 能触及什么。Agency 告诉你 agent 被授权在什么条件下、基于什么证据、承担什么后果去做决定。

这个区别听起来很小——直到第一次糟糕的运行。

一个只读的调研助手浪费的是时间。一个有账单权限的 agent 能制造债务。一个有邮件权限的 agent 能代表公司发言。一个有部署权限的 agent 能把一个错误的推断变成基础设施。

更多的工具不会自动让 agent 更有 agent 性。

更多的工具只是扩大了需要精心设计判断力的表面。

工具栈是可见的。契约栈是承重的。

可见的 agent 栈列出来很容易：模型、prompt、memory、工具、MCP 服务器、子 agent、框架、evals。

这个栈很重要。但它也不是操作系统。

操作系统是每一层创建的契约集合。

agent 的目标是什么？它可以看到什么状态？它可以保留什么状态？它可以调用哪些工具？哪些工具故意不提供？它可以改变什么？什么必须在变更生效前被证明？harness 记录什么？评估分数实际覆盖了什么？agent 什么时候该问、什么时候该放弃、什么时候该升级？

这才是真正的搭建方案。

不是工具清单。

而是决定工具意味着什么的边界集合。

通用的搭建栈问的是你接了什么。

契约栈问的是你可以信任什么。

Agent 是一个控制循环，不是一个有野心的 prompt

Agent 是一个包裹着生成器的外层控制循环。它规划、读取状态、选择工具、行动、观察、修复、升级，并决定是否继续。

失败很少发生在一个光鲜亮丽的地方。

它可能出在 planner。可能出在 retrieval。可能出在工具描述。可能出在重试逻辑。可能出在一个隐藏假设——世界是否在 agent 思考时等待。

这就是为什么框架比较往往没有看起来那么有用。

真正重要的区别是：循环的哪些部分足够显式，可以被检查。

如果规划隐藏在一长串自然语言指令里，你就没法不重写整个 prompt 来修复规划。

如果 memory 只是不断增长的 transcript，你就无法判断 agent 是记住了、检索到了、推断出了、还是幻觉出了某条内容。

如果工具调用没有日志，你就无法判断答案是因为模型推理错误还是因为调用了错误的工具。

如果评估只是一次最终的通过/失败数字，你就无法判断 agent 是在发现阶段、参数阶段、排序阶段、恢复阶段、升级阶段还是判断阶段失败。

Agent 变得可靠，不是因为搭建变得更炫酷。

而是因为失败有了一个明确的位置可以落地。

MCP 不是魔法胶水

MCP 很重要。Skills 很重要。Connectors 很重要。

但它们的重要性经常被反向描述。

偷懒的说法是：MCP 有价值是因为它给 agent 更多工具。

更好的说法是：MCP 有价值是因为它让工具边界足够显式，可以检查、版本化、测试、授权和调试。

工具不是中立的管道。工具描述告诉一个非确定性系统一个动作意味着什么。名称、参数、返回格式、错误消息和允许的变更都会改变行为。

为人类开发者构建的工具，不自动成为对 agent 好的工具。人类带着缺失的上下文。Agent 需要契约被写下来。

这就是为什么更多工具可能让 agent 变差。

在小规模下，工具访问感觉像自由。在大规模下，工具访问变成了搜索。agent 必须识别正确的工具、传递有效的参数、从部分失败中恢复，并且在工具调用失败时不去编造一条成功的执行轨迹。

如果你把每个 API 端点都暴露为工具，你拥有的不是一个强大的 agent 表面。

你拥有的是有写入访问的词汇问题。

成熟的行动不是"连接一切"。

成熟的行动是设计最小的工具表面，让 agent 能完成任务，然后让每个工具契约都可解读。这个工具做什么。什么时候该用。返回值证明了什么、没证明什么。失败是什么样的。哪些调用是只读的，哪些会变更状态，哪些需要审批。trace 走向哪里。

这才是防止 transcript 成为你操作系统唯一存在地点的方法。

Skills 不是 prompt 片段

同样的错误也发生在 skills 上。

人们把 skills 当作更好的 prompt 来对待：一个 SKILL.md、几个例子、一些指令、可能再加一个脚本。有用。可移植。易于分享。

但一个严肃的 skill 不是一段 prompt。

它是打包好的操作知识。

它应该包含触发条件、流程、边界、坑点和失败模式。

"坑点"往往是最有价值的部分。模型通常已经知道happy path。它不知道的是你本地的伤疤：哪个 API 会骗人、哪个文件不能编辑、哪个命名约定会破坏部署、哪个客户细分会改变策略。

这就是为什么通用 skill 目录有天花板。

它们可以教模型通用工作流。

除非你自己打包那些知识，否则它们没法教模型你的工作流中哪些部分是承重的。

Skills 有价值是因为它们让操作知识可以在会话和 agent 之间迁移。它们危险 when they activate at the wrong time、when they implicitly compose into deeper graphs nobody intended、或者 when they grant state-changing behaviour without a permission contract。

真正的问题更尖锐：

当这个 skill 被激活时，它被允许影响什么决定？

如果没人能回答这个问题，这个 skill 只是更持久地做错误行动的方式。

Memory 是被治理的状态，不是一段更长的过去

Memory 有同样的问题。

每个 agent 产品都想承诺 memory。听起来理所当然。agent 应该记住用户、项目、codebase、客户历史、之前的决定、上次的错误。

但 memory 不是"更多上下文"。

Memory 是一个四部分契约：写什么、怎么组织、怎么检索、怎么治理。

如果 agent 写太多，memory 就变成淤泥。

如果它总结得不好，memory 就变成扭曲。

如果仅靠相似性检索，memory 就变成有引用的直觉。

如果它永远不忘，memory 就变成上下文中毒。

如果它无法说明为什么使用了一条 memory，memory 就变成看不见的权威。

值得问的 memory 问题是：

哪些状态应该存活因为它们会改善未来决策，哪些状态应该过期因为它们会毒害未来决策？

这是一个契约问题。

这也是为什么一个维护良好的 500 字项目笔记可以胜过一段巨大的聊天记录。较小的笔记有职责。Transcript 只有体积。

Harness 是自主性变得可衡量的地方

大多数 agent 演示让模型看起来像主角。

在生产中，harness 才是主角。