OpenFang 是我们内部维护的一个多步骤 AI Agent今年年初我把它的自主性调到了比较激进的一档。结果第三周就出了事它按照预设目标自己拆解了六个子任务调用了文件服务、数据库查询和消息推送一气呵成地跑完了整个流程——但把所有待归档文件挪到了错误的目录还顺手改了另一个小组业务表的读取权限。复盘的时候某位同事说了句我到现在都记得的话它不是不够聪明它是太能干了但没人告诉它什么不能碰。这个教训让我彻底改变了对 Agent 的看法。过去我和大多数人一样以为 AI Agent 的难度全在自主上多步规划、工具调用、自我纠错每一项都不容易。但真正把 OpenFang 推到接近生产的状态之后我才发现在自主性背后还有另一个更隐蔽、也更折磨人的难题——治理。自主解决的是能不能做治理解决的是允不允许做、做错了怎么办。这篇文章就把我从 OpenFang 上踩出来的这些经验完整梳理一遍给同样在做 Agent 的朋友当个参考。1. 一次把我从能力竞赛里拉出来的故障复盘1.1 事故是怎么发生的OpenFang 当时的任务目标是自动整理并归档运营报告。它接入了文件服务、数据库查询和群消息推送三组工具支持用自然语言描述目标、自己规划步骤。最初的配置里我给的权限相当大方读写文件、执行 SQL 查询、发送消息基本全开。当时的想法很朴素——不给够权限它怎么帮你干活那天深夜任务被触发。OpenFang 自己规划了六步查询昨日报告、按周生成汇总、列出待归档清单、移动文件、更新索引、推送完成通知。前三步都很正常问题出在第四步。它把待归档目录之外的一批近期文件也一并挪进了归档区理由是这些文件看起来属于同一批报告。随后更新索引时它又推断这个表与归档任务相关给另一个小组的业务表改了读取权限。第二天早上运营反馈文件找不到IT 反馈权限变更异常。我翻 trace 的时候发现OpenFang 每一步都有合理的自我解释——它不是乱来而是在上下文里做了过度联想和推断。最扎心的是模型层面的能力和执行层面没有隔离它认为合理的事情系统就真的允许它做了。1.2 复盘后我才想明白的问题当时我还试过一条很费劲的路把 prompt 越写越长反复强调禁止修改权限禁止移动非目标文件不要碰其他目录。结果变化不大。模型不是看不见这些规则而是当上下文变长、任务变复杂之后它很难在每个执行节点都稳定地记住并遵守所有约束。写在 prompt 里的规则是叙事性的本质靠模型自觉而系统真正需要的是结构性约束——不依赖模型判断、由运行环境强制执行的边界。那次之后我才真正理解一个道理Agent 的性能上去了不代表风险会自动降低。恰恰相反能力越强单位时间内能造成的错误动作就越多扩散也越快。这种动量效应没法靠模型自己消化只能靠外部治理机制来兜底。2. 自主是能力问题治理是边界问题2.1 把该做什么和允许做什么拆开先说清楚这两个概念。自主性回答的是如何完成任务规划、拆解、调用工具、根据反馈修正这是能力问题。治理回答的是在哪些范围内完成任务哪些工具能用、哪些路径可写、哪些动作需要审批、出了错怎么回滚这是边界问题。可以类比成招了一个非常聪明的实习生。能力越强你越会放心把重要任务交给他但前提是公司得有一套清晰的岗位权限和审批流程。你不会让实习生凭自己的判断去决定银行转账金额也不会让他去修改财务系统的权限配置。Agent 也一样意图来自模型边界来自系统。OpenFang 最开始的架构完全没做这个区分。模型的推理链直接映射到工具调用中间没有边界校验、没有风险分级模型觉得该做就等于系统允许做。那次事故本质上就是这层缺失的体现。所以我后来在做架构调整时第一原则就是让模型说和让系统做彻底分离模型可以表达意图但执行必须经过治理层。2.2 Agent 治理的三层结构意图、权限、审计我在这个过程里逐步把 Agent 的治理拆成了三层每一层解决一类典型问题治理层回答的问题典型故障模式对应手段意图层Agent 打算做什么、为什么这么做幻觉、过度推理、目标偏离工具说明约束、任务边界描述、自我校验提示权限层系统实际允许它做什么越权操作、误操作、批量破坏工具白名单、最小权限、沙箱、审批节点审计层它到底做了哪些事、影响范围多大故障不可溯源、责任难界定全链路 trace、决策理由记录、异常告警只做其中任何一层都不够。只做意图层相当于把安全寄托在模型自觉上OpenFang 已经替我验证了这条路走不通。只做权限层能挡住越权但挡不住它在权限范围内做出荒谬决策而且没有审计出了问题连复盘都无从谈起。只做审计层最被动那是事后追责不是事前防范。三层合起来才形成一个闭环意图层让模型在思考时就有边界意识权限层在物理上堵住越界动作审计层保证每次越界尝试都能被看见、被追溯。这也是我后来给 OpenFang 做改造时的总体框架。3. OpenFang 从能干到可控的四层改造实践3.1 工具权限分级从全量授权到最小权限第一件事是把所有工具重新梳理一遍按操作风险分级不再搞全量授权。我最终采用了一种三级分类只读类查询数据、读取文件、检索信息。这类动作基本无害默认允许但会限制访问范围。写操作类移动文件、编辑内容、创建目录。这类动作会影响数据状态需要白名单路径必要时追加二次确认。高影响类权限变更、删除文件、批量执行、对外发送消息。这类动作必须走独立审批流且强制强化审计。每一类工具在注册时都要带一份声明写清楚它能做什么、不能做什么。下面是我整理出来的权限清单格式示例{ tool: archive_files, permission: whitelist, allow_paths: [/data/reports/archive/], deny_paths: [/data/other_team/], side_effect: write, risk_level: medium, confirmation: auto_when_path_in_whitelist }这套机制起到的作用很直接即使模型在推理时觉得某个文件应该归档只要它不在白名单路径里工具层的拦截就会生效。模型可以表达意图但能不能落到执行上由权限规则说了算。这就是前面说的结构性约束。3.2 任务沙箱把爆炸半径圈在一个任务里第二层改造是引入任务级沙箱。每个 Agent 任务运行在独立的临时目录和隔离环境里它接触到的文件、配置、中间产物全部限制在这个范围。任务完成后再把需要保留的结果合并出来。如果任务失败或出现异常直接丢弃整个环境。这样做最大的好处是把爆炸半径圈定在单个任务内部。没有沙箱的时候一个 Agent 的误操作可能污染共享目录、影响其他任务上了沙箱之后最坏情况也就是这个任务本身报废不会波及其他正在运行的流程。我通常还会在任务开始时打快照一旦发现连续失败或高危动作被拦截就自动暂停任务并保留现场等人工决定重跑还是回滚。对不同场景说明一下不是所有 Agent 都需要这么重的沙箱。如果是纯问答、纯文本生成风险很小但只要 Agent 会写文件、改配置、发消息、调数据库强烈建议至少做到任务级隔离。这是成本最低、见效最快的治理手段之一。3.3 审计追踪记录做了什么还要记录为什么做第三层是重做审计体系。最开始我的日志只记录工具调用的参数和返回结果出了事故根本不够用因为我不知道 Agent 为什么这么调用。后面我把 trace 结构改成了同时记录动作和决策依据每个步骤大致包含这些字段{ task_goal: 归档本周运营报告, current_step: 4, tool_call: archive_files, input_summary: 移动 2024 年所有报告文件至 /data/reports/archive/, model_reasoning: 这些文件与本周报告标题格式一致推断为同批待归档文件, result_status: blocked_by_path_policy }关键在于model_reasoning这个字段很值钱。它记录的是模型在做出该动作前的自我解释出问题的时候能直接看到是哪一步的推理偏离了目标。上次权限事故如果一开始就有这个字段我根本不用翻几十条日志去猜打开 trace 就能定位到第四步归档范围判断错误。这里有个细节记录推理摘要会带来额外的 token 和存储成本但和事故排查成本比起来完全值得。建议只保留摘要而非完整思维链信息量的损失很小成本却能降一个数量级。3.4 人工介入点给 Agent 留一个刹车第四层是人工介入机制。全自动的 Agent 看着很爽但真正上手之后会发现完全没有刹车的全自动在生产环境里就是灾难。我给 OpenFang 设置了三种介入方式事前 checkpoint高影响类动作执行前强制人工确认从根上阻止高风险操作。事中干预接口任务运行中随时可以取消、改目标和回滚不需要等任务自己跑完。自动熔断条件比如连续三次工具调用失败、动作频率异常升高、检测到越权拦截系统自动暂停任务并通知人工。这套机制的核心不是凡事都要人点头而是让风险等级和人的参与程度匹配。日常低风险动作全自动高风险动作必须留一档人工。这样既保住了 Agent 的效率优势又给团队留了可控的干预窗口。4. 治理最容易翻车的两个地方4.1 约束过头Agent 变成了人工确认点击器第一次改造的时候我犯了个矫枉过正的错误为了安全给所有工具调用都加了人工确认。结果一个本来五分钟就能跑完的多步骤任务变成每一步都要等人点一下Agent 的优势被彻底抹掉了。团队成员很快开始抱怨说这哪是 Agent分明是个自动生成工单的点击器。后来调整的思路是按操作的风险等级和可恢复性来定确认粒度。只读动作全自动写操作在白名单路径范围内且可恢复的自动放行只有不可恢复的、跨边界的、高影响的动作才强制人工确认。这里有个经验判断一个动作需不需要人先问两个问题——做错了能回滚吗影响范围可控吗两个答案都是肯定的就让它自动跑有一个是否定的就加审批。4.2 审计数据变成了没人看的噪音第二个坑是我把治理做成了数据堆砌。全链路 trace 全部落库目标是只要出问题就什么都能查到结果平时根本没人看出问题的时候又因为数据量太大真正有效的线索被淹没在噪音里。后来我改成两层设计一是关键节点摘要每次任务只保留目标、最终结果、高风险动作这几项核心信息二是异常检测告警把权限拦截、连续失败、超时、步骤偏离原计划等事件实时推送给负责人。这样日常只需要看摘要和告警深度排查时再打开全量 trace。治理系统自己不能变成新的故障点它得学会该细的时候细、该粗的时候粗。还有一个经常被忽略的点治理策略不是上线就完事的。每给 Agent 加一个工具、每个新场景上线都要重新过一遍权限清单和审计规则。能力在演化边界就必须跟着演化这是持续维护不是一次性配置。5. 治理落地之后OpenFang 才真正变成了可用的工具5.1 一次无人值守任务里的实战验证改造完成大概两周后OpenFang 遇到了一次真正的考验。有个任务是夜里无人值守时自动汇总跨团队的运营数据跑到一半Agent 发现某个指标缺字段于是自己推断另一个部门的数据库可能有这个字段尝试直接访问查询。放在旧架构里这就是一次越权读取而且是夜间发生、无人知晓的那种。但在新架构下权限层直接拦截了这次访问审计日志里能看到它的完整推理链条——因为字段名匹配推断该库包含所需数据。系统按规则暂停了任务第二天早上我收到告警看了 trace 之后补了一个明确授权的数据源让任务重新跑了一遍十分钟解决。这个案例让我很受触动。因为问题不在于 Agent 的判断是否合理而在于系统有没有能力在它越界的时候兜住。治理的价值不是把 Agent 限制成一个只会按部就班的工具而是让团队敢于把更重要、更复杂的任务交给它因为你知道就算它判断失误后果也是可控的。5.2 治理让团队从不敢用到放心用现在回过头看OpenFang 真正从演示品变成工具转折点不是某个模型版本升级也不是某个推理能力突破而是治理体系补上来的那一刻。自主性决定了它的上限治理决定了它的下限。很多时候我们太关注上限恨不得 Agent 什么都会、什么都敢干却忘了没有下限保障的系统根本走不到生产环境。我后来和几个也在做 Agent 的朋友聊天发现大家真正被卡住的点惊人的一致几乎都不是模型不够聪明而是我还不敢让它单独干活。模型能力一直在进步但治理方法论、权限设计、审计体系这些其实是每个团队要自己补的功课。最后分享一个我自己的判断标准吧。现在再看到别人讨论 Agent 能力我已经不太关心它能做什么了我更关心另一组问题它在边界内能不能稳定完成任务如果越界了我能不能第一时间知道知道了能不能拦下来拦下来之后能不能恢复现场这三个问题都有了肯定的答案Agent 才真正从玩具变成了工具。
