企业官网建设流程全解析

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 的治理拆成了三层，每一层解决一类典型问题：

只做其中任何一层都不够。只做意图层，相当于把安全寄托在模型自觉上，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 才真正从"玩具"变成了"工具"。