两年前,把模型接到一个内部系统上,意味着写一个适配器。每个集成都有自己的一份:手写的 schema、为这一次场合发明的认证路径、和别处都对不上的序列化格式,以及只在有人被咬过的地方才存在的错误处理。这些适配器能用,然后腐烂,而每一个都是只有作者本人能维护的小型私有方言。
这一层现在是一份有标准组织在背后、并且在厂商与企业间广泛落地的协议。工具接入不再是每个团队各自发明的东西。
这是一次真实的简化,而它被误认成了一次更大的简化。工作没有消失。它转移了 —— 从”写连接”转移到”治理连接”。
标准化实际消除了什么
三项成本,都是真的:
方言问题。 一份工具描述,现在对不同的客户端意味着同一件事。能力发现、参数 schema、错误形状 —— 这些每个团队都在各自发明的东西 —— 现在可以互操作。适配器不再是那件产出物,工具才是。
重写税。 过去,换掉工具集前面的模型或客户端,意味着把集成层重做一遍。这个耦合基本上消失了,而它的价值比听上去大:模型层的可替换性是一种韧性属性,而它此前昂贵到团队干脆放弃拥有。
维护底线。 标准的传输与标准的错误语义,意味着那些无聊的部分不需要谁去人格化地拥有,也能保持稳定。
它交还了什么
一旦”接上”变容易,难点就迁移到了权限。现在真正消耗工程时间的问题,不是关于线格式的:
一个 agent 可以碰哪些系统、在什么状态下碰? 一个工具面不是能力清单,它是攻击面和爆炸半径。“既然暴露很便宜就全暴露”的本能,和窗口变长后”既然放得下就全放进去”的本能是同一个,失败的方式也是同一个。
一次调用以谁的权限执行? 这是标准化让人无法回避的那个问题。以服务账号权限行事的 agent,并不是以那个向它提问的用户的身份在行事 —— 而这个区别会在某个 agent 读到提问者本来无权看到的东西时,第一次显形。身份必须沿着调用链传播,而不是停在链条的入口。
写路径要求什么? 读权限和写权限是两个不同的产品。我们要求写操作有明确的意图确认、保持幂等以致重试的步骤不会重复生效、并让每一次写要么可逆、要么有界。一个 agent 在超时含义不明时重试是正常的;一条扛不住这种重试的写路径是缺陷。
它到底做了什么? 工具调用与调用结果,应当连同授权它的身份一起进入审计轨迹,并按照任何其他特权系统访问同样的标准留存。出事时要问的从来不是”模型说了什么”,而是”它碰了什么、以谁的权限、返回了什么”。
一个不可信的工具响应意味着什么? 工具结果是数据,不是指令。经由工具取回的内容里可以包含看起来像指示的文本,而一个守不住这条边界的系统,等于把 agent 的控制权交给了任何能往它所读取的系统里写字的人。这是这份清单上后果最重的一条,而它不是协议能替你解决的。
我们据此怎么建
- 工具面按任务划定,不按系统划定。默认什么都不暴露;每一个工具的准入都要有人写下理由。
- 读路径与写路径分开,审批不同、日志不同、eval 的处理方式也不同。
- 用户身份传播到调用上。服务账号的便利只对后台路径开放,而这些路径不能直接服务面向用户的答案。
- 工具响应在每一步都按不可信输入对待 —— 包括它来自我们自己拥有的系统时。
- 每个工具都要为失败定义行为,而这个行为在 eval 套件里被演练,而不是在事故里被发现。
底下的那个模式
某一层的标准化不会消除那一层的工作。它把工作向上迁移,迁到标准刻意留白的那些问题上 —— 而那些问题通常正是关于权限与后果的。
胶水没有了,这是真实的进展。剩下的,是一直以来真正属于工程的那部分:决定一个系统被允许做什么,以及事后能证明它做了什么。