今天群里聊到一个现象，大家都在期待 Agent 越来越强。最好它能自己读需求、自己规划、自己改代码跑测试。我也这么期待。但聊着聊着我发现自己心里有个矛盾的感受：Agent 变强之后，我并没有更放心。
以前它只能写一段函数，出了问题我一眼就能看到。现在它能自己拆任务、自己决定执行顺序、同时改好几个模块，我坐在旁边反而开始猜：它到底在干什么？
这个焦虑不是因为它做错了什么。恰恰是因为它做的事太多了，多到我跟不上。
这跟带团队是一回事
我后来想明白，这跟带团队是一回事。
团队里有个高级工程师，你信任他，不是因为他代码写得快。你信任的其实是一组行为模式：他知道什么时候该自己决定、什么时候该来问你；他改代码前会说一句"这块我打算这样动，影响面是这些"；他遇到不确定的事情会直接说"这里我不确定"，而不是假装确定然后给你埋雷；他交付的时候会告诉你怎么验证。
反过来，如果一个人技术很强，但每次接了任务就消失两天，回来直接甩一坨代码，中间没有任何同步。你不会因为他强就更放心。你会更紧张。因为他能改的东西太多了，速度又快，万一方向偏了，等你发现的时候已经来不及了。
Agent 现在就处于这个位置。它能力够强了，但还没建立起那套让人放心的协作行为。
不是"展示推理过程"，而是建立责任链
很多人觉得解决方案是"让模型思考过程可见"，把 chain-of-thought 展示出来。我觉得这搞偏了。你跟一个高级工程师合作，不需要他把每一个脑内念头直播给你看。你需要看到的是几个关键东西：他接的目标是什么、他打算怎么分步、哪些操作会动真实系统、哪里他自己也不确定、做完之后怎么证明是对的。
这不是"展示推理过程"，而是建立责任链。
有人会说，那加个运行日志面板不就行了？把每个 tool call、每次文件修改都列出来。
这只解决了"可见"，没解决"可托付"。日志是给你事后排查用的，不是让你在过程中建立信任用的。真正的托付需要的是另一层东西。
四个条件
我试着拆一下，Agent 要让人敢把事情交出去，至少需要四个条件。
第一个是上下文契约。Agent 动手之前，它得清楚哪些是这次任务的背景，哪些是长期不能碰的规则。不然它就像个新来的外包，听了两句需求就开干，短任务还行，稍微复杂一点必然漂移。
第二个是身份边界。它到底能做什么不能做什么？能直接改代码还是只能建议？能动配置吗？能访问线上数据吗？这些不说清楚，用户就没法判断自己到底把什么权力交出去了。
第三个是关键节点的暴露。不需要事无巨细，但计划、当前进度、遇到的不确定性，这几个点要主动说出来。让人不用猜。
第四个是验收证据。不能只说"我做完了"。做完了，怎么证明？测试跑了没？改了哪些文件？有没有回滚的办法？如果"完成"只是它说的一句话，那这句话就不值钱。
这四个加在一起，我把它叫做"托付基础设施"。不是什么高深的架构，就是让人敢交事出去的底座。
分层，跟管人一模一样
还有一个常见的误解：搞这些是不是在"把控制权拿回来"？是不是又要人盯着 Agent 每一步？
不是。如果每一步都要人看，Agent 就没意义了。好的做法是分层。低风险的事情让它自己干，比如读文档、写草稿、跑本地测试。中风险的事情需要它主动暴露过程，比如跨模块的重构、改核心配置。高风险的事情必须停下来等人确认，比如删数据、发外部通知、合并到主分支。
这个分层跟管人一模一样。你不会要求高级工程师每写一行代码都来找你签字，但他动核心架构之前你需要知道。Agent 越强，这种分层越重要。不然它就变成了一个很拧巴的存在：干活像高级工程师，权限像临时外包，汇报像黑箱脚本。
光看结果不够，得看过程
过去用软件，你只需要信任结果。点个按钮导出报表，报表数字对就行，过程无所谓，因为执行路径是固定的。但 Agent 不一样，它的过程是动态的，会根据情况调整路径，信息不够会做假设。这意味着结果看起来对，不代表中间没有问题。它可能绕过了某个约束，改坏了某个边缘 case，只是暂时没暴露出来。
所以对 Agent 的信任，光看结果不够，得看过程。系统要能回答：它为什么走这条路？依据是什么？有没有越过用户设的边界？
这才是 Agent 从 demo 走到日常使用的真正门槛。不是模型够不够聪明的问题，是用户敢不敢把真正重要的事情交给它的问题。
我现在越来越觉得，Agent 产品的核心词不应该是"自动化"。自动化关心的是效率，是机器替人干活。但当 Agent 进入复杂任务，用户真正在做的事情是"托付"：把一段责任交出去，同时需要知道边界在哪、出了问题谁接住、怎么验证没走偏。
未来好的 Agent 基础设施可能一点都不炫。不是什么多 Agent 编排图，不是满屏的执行日志。就是一套朴素的东西：清楚的契约、稳定的上下文、分好的权限、关键动作前停一下、做完了能证明。
这些东西不性感，但没有它们，Agent 再强也只是个让人不放心的强。