两年前，把语言模型接入 CRM，要占掉项目计划的四分之一。如今，一位合格的工程师午饭前就能做完。
集成的麻烦，其实一直兼着一份没人列进预算的差事：公司掏钱之前，总得有人说清这个连接凭什么值得。要花 3 周的时候，经理会追问这个工具拿来做什么；只要 20 分钟，就没人再问了。
这道关口没了，也没有什么东西顶上。
随之而来的是三项成本，而且三项都落在高管头上，不在工程师头上。
三项成本，一个病根
每项成本落在谁身上
| 成本 | 表现形式 | 由谁承担 |
|---|---|---|
| 上下文预算 | 回答变含糊，账单变高，工具选错 | 签批模型支出的人 |
| 三方安全 | 以您的名义执行、却没人授权的操作 | 在 GDPR 处理活动记录上签字的人 |
| 没人问出口的问题 | 智能体在干一件脚本干得更好的活 | 明年要为预算辩护的人 |
这三项都不是协议本身的缺陷。决策关口一消失、又没有东西补位，就会出现这些问题。
工具清单也要收租
智能体能调用的每个工具，都要先向它描述清楚，而这些描述在模型读到您请求的第一个字之前就已载入。一年下来加了 30 台服务器，每台花 20 分钟，如今每一次，菜单都抢在饭菜前头上桌。
某个工作流原先让工具定义和中间结果都从模型过一遍，耗用约 150,000 个 token；重构后只需约 2,000 个，降幅 98.7%。
来源：Anthropic，《Code execution with MCP》，2025 年 11 月
别把 98.7% 当成您的数字。照着这个思路算一算自己的账：请求之前载入的 token 数，乘以调用量，再乘以您的单价。这道乘法，大多数团队从没算过。
Sebastian Wallkötter 在 2026 年 2 月接受 KDnuggets 采访时给过一个好用的参照：200,000 个 token 的窗口，大致相当于一整部长篇小说。多数人当它取之不尽，这样一比，它就成了一份有边界的预算。
这有限的空间里，几方都在争位置，而它们的分量并不相等。
窗口被谁占用
| 占用窗口的内容 | 结论 |
|---|---|
| 工具定义，预先加载 | 可以：改为按需载入 |
| 在模型中往返的中间结果 | 可以：留在执行环境中 |
| 检索到的文档 | 部分可以：改进检索 |
| 您的经营上下文：规则、格式，以及在您这里怎样才算好 | 不能，这恰恰是您花钱要买的 |
要害在最后一行。
编排和工具目录都可以买，上下文买不来，而工具清单正在把它挤出窗口。
我们在《平台可以买，上下文买不来》一文中对此有过详细论述。
您的管控假定只有两方，实际上有三方。
这笔交易里有哪几方
| 参与方 | 声称的身份 | 管控是否核查 |
|---|---|---|
| 本人 | 提出请求的员工 | 通常核查 |
| 模型提供商 | 代表该员工行事 | 很少，且并非逐项操作核查 |
| 被调用的服务 | 认可别人交给它的令牌 | 只核查令牌是否有效 |
会出现在处理活动记录里的，是中间那一行。
智能体若转移了个人数据，记录上就得写明它奉的是谁的指令；“助手自己决定的”这种说法，任何审查都过不了。
标准已经往前走了。2024 年 11 月发布的首个版本，完全没有授权框架。2025 年 3 月引入 OAuth 2.1，2025 年 6 月的修订版则让服务器成了真正意义上的资源服务器。
部署却没有跟上。
已识别的 7,973 台在线远程 MCP 服务器中，40.55% 开放的工具不设任何认证机制。接受动态测试的 119 台启用 OAuth 的服务器，台台至少有一处缺陷，合计 325 处，由此产生 9 个 CVE 编号。
来源：《A First Measurement Study on Authentication Security in Real-World Remote MCP Servers》，arXiv:2605.22333 · 2026 年 5 月
认证是能啃下来的那一半。另一半是提示词注入：工具返回的内容夹带指令，模型便照着执行。人们常盼着有一种办法，能像当年封住 SQL 注入那样一劳永逸：把指令和数据分开。
SQL 注入之所以能解决，是因为查询结构和用户数据在原理上可以分开。而在语言模型里，两者本就是一回事。
两年过去，所有缓解措施都只是概率意义上的。哪一周有人证明情况并非如此，我们当周就放弃这一看法。
落到实处，后果很具体：智能体能调用的每个工具，凡是能往其上下文里写入内容的人都能用。工具数量，就是爆炸半径。
最省钱的解法，往往不是 AI
Wallkötter 博士阶段研究人机交互，他形容人形机器人“有点像一种不稳定的平衡”：演示时惊艳，一旦有人追问它到底干什么活，就很难自圆其说。把腿卸了，装上轮子，得到的东西更便宜、更结实，只是没人会去拍它。
他在软件里撞见的同类情形：一套精巧的编程系统，配了一个智能体，专门识别不可靠的测试。可只要把测试跑 10 遍，时过时不过，它就是不可靠的。这个词本来就是这个意思。
确定性的版本瞬间出结果、不花钱、次次正确，也不用做安全审查。智能体版本要耗 token，偶尔出错，还给本已拥挤的工具清单再添一行。
模型物有所值的地方，是在模糊情境中做判断。只要答案有一个写得下来的定义，模型就会输给脚本。
四个问题，就能把各种情况分开：
依次提问
| 检验 | 问题 | 对策 |
|---|---|---|
| 规则 | 输出能不能用一条写得下来的规则来检查？ | 写规则。 |
| 一致性 | 同一输入，是否必须次次给出同一答案？ | 选错了工具。 |
| 爆炸半径 | 答错的代价是否高昂，而且不易察觉？ | 用脚本；或者用模型，但在执行操作前加一道人工检查。 |
| 判断 | 输入是否为非结构化语言，判断是否真的模糊？ | 这正是模型的用武之地。 |
交给我们评审的智能体项目，多数在第一个问题上就站不住，而且从来没人验证过，因为那个朴素版本根本没人做。
收窄智能体，写下工具预算
在我们参与的项目里，一个挂 40 个工具的智能体，始终打不过 4 个各挂 6 个工具的智能体。负责给请求分派路径的组件，只有在分得清各个选项时才能选对。定方案之前，先拿自己的真实流量测一测。
让这一切落到实处的管控手段，比架构乏味得多：每个智能体一份书面工具清单，每一项都写上负责人和理由。想加一个，就得删一个，或者把理由讲透。
本周就做：列出您的智能体眼下能调用的全部工具，逐一写上负责人和理由，再数数有几个没人说得出理由。这只要一个小时，而那个说不出理由的数字，往往就是诊断结果。
反对意见：有人会说，按需载入已经解决了问题。它只解决了三项成本中的一项。只在需要时载入的工具照样存在，照样要维护，也照样能被调用。
token 账单，从来都是三项中最不值一提的。
先把笨办法写下来
上面所说的一切，都默认这个智能体该存在。真正能诚实检验这一点的时机只有现在：趁谁都还没有需要辩护的东西。
接通之前，先写下三样东西：
底线：质量底线，附上日期。
上限：调用量真正上来之后，单次运行的成本上限。
基线：确定性基线，也就是这项任务最朴素的非 AI 版本，以及它实际表现如何。
真正起作用的主要是第三样。如果没人说得清脚本版本长什么样，说明团队对这项任务的理解还不足以把它自动化。如果脚本已有，而智能体领先的幅度抵不过运营成本和新增的攻击面，那么一天就能得出答案，不必耗上一个季度。
这就是我们 AZIMUTH 方法中的 Bearing（定方位）阶段，详见方法页面。客户总爱跟它较劲，直到某个季度，它赶在项目自行崩掉之前先把项目叫停。
协议省掉了一项成本，却从没省掉它背后的那个决定。
最近审阅：2026 年 8 月。更正一律留档，绝不悄悄改动。什么能改变我们的立场：一种在对抗性测试下依然站得住、而不只是平均表现过关的提示词注入缓解措施。
