【AI 杂谈】Agent的信任壕沟：为什么越强的Agent越没人敢用？

Agent的信任壕沟：为什么越强的Agent越没人敢用？

信号：六家公司不约而同在回答同一个问题

2026年6月下旬，六家公司的六条信息各自独立出现，彼此之间未必通气，但它们共同指向了一件事。

Claude Code的工程一号位Fiona Fung在访谈里说：该算ROI了，“狂烧Token的时代已经过了”。她补了一句更值得琢磨的话——“信任是AI公司最难自动化的东西”

几乎同期，微软在Build 2026上发布了Microsoft Scout——一款被归类为"Autopilot"的新型常驻智能体。从Copilot到Autopilot，产品形态只差一个词，但意思差了十万八千里。Copilot在旁边给建议，审完了人决定做不做；Autopilot这个新品类替你做，你只需要看着。一字之差，越过的不是功能，是信任。

本月上旬Build大会上，GitHub发布了Copilot App，把分散在十几个地方的Agent汇集到一个入口。你以为这是在解决"太散了不好找"的问题——不是。它的底层问题是：当一个人同时跑着五个Agent，他实际上在管理五个半自主的数字员工。管理半径不够用了。

5月下旬，GitLab 19.0把Agentic AI放进了凭证管理和供应链安全。这不是技术升级新闻，这是一个信号：Agent的犯错半径，从"写错一行代码"扩大到了"泄露生产凭证"。过去Agent出问题是bug，现在Agent出问题是事故。

阿里云在同一时期讲了一个新概念：Agent不是云的"一个用户"，而是"核心用户"。这意味着云计算的身份模型得改了——过去是"人操作资源"，将来是"人授权Agent、Agent操作资源"。中间多出来的这一层，整个身份体系还没准备好。

还有一条最容易被当成纯技术方案略过的信息——Uber和Auth0在联合设计多Agent之间的身份传播架构。他们在回答一个比前面所有问题都更根本的东西：Agent到底是"我"还是"它"？如果是"我"的延伸，它可以继承我的权限；如果是独立实体，它需要自己的身份、权限和责任边界。这个问题今天不回答，上面所有架构都是建在沙子上。

六条信息，六个维度——经济层、产品层、体验层、安全层、基础设施层、身份层。各自在各自的领域独立作业，撞上的是同一堵墙。

这堵墙不是Agent不够强。恰恰相反：它强到我们已经没有制度框架来信任它了。

解剖：信任壕沟的五层结构

Agent撞上的不是技术墙，是制度墙。这堵墙有五层，不是并列关系，是递进依赖——上一层不稳，下面全白搭。

第一层：身份。Agent是"我"还是"它"？

这是所有信任问题的起点。Uber和Auth0干的事看起来是工程问题，本质上是治理问题。当一个Agent登录你的GitHub、审批你的合并请求、管理你的生产凭证，它到底是以"你的工具"身份，还是以"一个被授权角色"的身份？

这个区别直接决定出事了找谁。如果是工具，出问题你全责——就跟锤子砸了手不能怪锤子。如果是被授权的角色，那就涉及授权边界、越权行为、代理责任——一套跟法人治理差不多复杂的东西。

Amazon的Alexa团队内部有一个准则：每个Agent在系统里都有一个独立ID，不与人类用户共享命名空间。为什么？不是为了技术方便，是审计需要——事后你必须能分清屏幕那头的每一次操作到底是谁干的（来源：AWS Agentic AI基础设施实践系列）。注：此细节源于AWS公开实践文档，非单一演讲内容。

第二层：授权。我给了它多大权力？边界在哪？

解决了"谁"，下一个是"能干嘛"。微软从Copilot到Autopilot的进化不是随便起的。自动驾驶行业有一个L1到L5的分级体系——L1是辅助驾驶，人主导；L5是无人驾驶，人完全放手。Agent缺的就是这样一个被普遍接受的信任分级。

参考微软Scout的设计方向和行业讨论，可以提炼出一个信任梯度的参考结构：建议模式（Agent给方案，人决定）→ 确认模式（Agent执行，关键操作需人确认）→ 自动模式（Agent在边界内自主执行，事后通知）。这不是技术路径，是信任梯度。不是"给不给权限"的二进制问题，而是"先给1%，证明自己再给2%"的渐进逻辑。

第三层：责任。Agent做错了谁负责？

Claude Code工程一号位谈ROI的时候，很多人听的是价格。但ROI算不出来，根源不在Token贵。根源在于：你不敢把足够多的任务闭环交给Agent，因为没人回答"搞砸了算谁的"。

API7.ai创始人温铭用几百亿Token重写生产级网关后，总结出"AI的能力已经溢出，真正跟不上的，是人"（来源：InfoQ，6月26日）。什么叫人跟不上？不是代码写不出来，是责任体系跟不上。Agent可以生成代码、修改配置、更新依赖——每一步都可能引入风险，但不存在对应的"Agent操作责任矩阵"。传统的变更管理流程里，审批人、执行人、验证人都有明确的人名。Agent塞进去之后，这一套人名逻辑就碎了。

第四层：审计。发生了什么事后我能查吗？

GitLab 19.0把Agent放进安全体系的同时，加了一套Agent操作审计日志。这是对的，但远远不够。今天的Agent决策链是黑箱——它改了文件、发了PR、合并了代码，你拿到的是一个结果，不是一段你读得懂的推理过程。

审计不是存日志，是"可复现性"。人做了错事，你可以把他叫过来问"当时怎么想的"。Agent的"想法"是一堆权重和概率分布，没人看得懂。这就是为什么可解释性不是一个学术趣味问题——它直接关系到审计能不能落地。

第五层：传导。多Agent之间信任如何复合？

这才是最被低估的一层，也是这些信息横向串起来之后才浮现的。

单个Agent的身份、授权、责任、审计已经够复杂了。但当多个Agent组成一条流水线——Agent A写完代码推给Agent B做代码审查，Agent B通过后触发Agent C部署——信任在不同Agent之间怎么传导？A的权限能不能被B继承？如果流水线中间出了事故，是A的错、B没拦住，还是C部署流程有问题？

阿里云说Agent是"核心云用户"，Uber在画多Agent身份传播的架构图，这两个动作放在一起看，说明一件事：信任传导不是一个未来才需要担心的理论问题。Agent流水线已经在生产环境跑了。信任传递机制还没开始设计。

这不是单靠写更多代码能解决的。行业目前在做的全在第一条线上——让Agent更强、更快、更准。但Agent已经够强了。五层信任壕沟，一层比一层深，一层比一层更没人碰。

出路：信任不是靠演示建立的

Agent行业的演示永远在回答同一个问题："你看它能做多少事。"但信任从来不是看演示建立的。信任是你在被允许犯错、被记录过程、被清晰追责的过程中，一点一点积累出来的。

从二进制的开关到渐进的信任梯度。

上一次面对"能不能信任机器"的问题，是在自动驾驶行业。没有任何一个自动驾驶公司跳出来说"我们的车不需要方向盘"。所有人都走了渐进路线：L1辅助、L2部分自动化、L3有条件自动化——每升一级，人后退一步，机器前进一步。

Agent行业现在面对的不是"要不要给Agent权限"，而是"给它1%的权限它能证明自己值得2%吗"。微软Scout的Autopilot模式和人工确认机制提供了一个产品层面的方向，但它只是一个开始。需要的不只是产品功能，而是一套可被独立审计的信任成熟度模型——有点像SOC 2合规，但不是为人类组织设计的，是为人-Agent混合团队的运作模式设计的。

可观测性必须先于自主性。

在Agent学会自主做事之前，它必须先学会解释自己。这个要求不新鲜——任何一个人类团队的新人加入，前三个月都是"你在做什么我都看着、都问"。Agent跳过了这个阶段，一上来就是个不解释的"熟手"，这才是让人不踏实的地方。

技术上做得到。OpenAI的论文已经证明模型可以生成推理链（来源：OpenAI o1 System Card）。问题在于，推理链不等于可审计的解释——前者是模型自言自语，后者是面向人类的可追溯逻辑。GitLab 19.0在Agent操作审计上是起步了，但整个行业需要从Agent设计的第一天就把"可解释性"作为必选项而不是加装包。

信任壕沟是新的护城河。

Claude Code工程一号位那句话值得再拿出来读一遍：“信任是AI公司最难自动化的东西。”

反过来理解这句话：谁先建立信任体系，谁就掌握了下一个时代的护城河。今天Agent的市场竞争是"谁的模型更强"，但模型之间的差距在肉眼可见地缩小。当大家的Agent都能写出差不多的代码、改出差不多的配置时，用户选谁？选那个"它干事我敢背锅"的。这不是道德选择，是理性选择——因为不确定性最低。

信任壕沟不是Agent行业的末日审判。你进到一条真正的战壕里，它保护你不被轰炸。跨过信任壕沟的Agent，才是从实验室走进生产系统的Agent。跨不过去的，就只是另一个做得不错的Demo。区别不在能力，在"你敢不敢把钥匙给它"。