企业官网建设流程全解析

目录

一、当自动化从个人效率工具变成公司资产

（一）一个成功得太快的问题

1、业务人员开始自己造工具

2、真正的风险不是 Agent 会不会回答，而是公司看不见它

（二）企业真正需要管理的是“行动权”

1、聊天工具与生产 Agent 的边界

2、把 Agent 看成“受约束的数字岗位”

二、Agent as Code：把自然语言能力纳入软件工程纪律

（一）为什么“代码化”比“写好 Prompt”更重要

1、Prompt 只是 Agent 的一个部件

2、Pull Request 是控制面，不只是开发流程

（二）标准模板如何释放非技术人员的生产力

1、把“空白页”变成“有护栏的起跑线”

2、真正的学习障碍是新的协作语法

三、渐进式自主权：让权限跟着证据增长

（一）“先建议、后执行”不是保守，而是数据策略

1、建议模式同时完成三件事

2、自主权必须按动作而不是按 Agent 一次性授予

（二）四道门：从影子运行到自动执行

1、第一道门：离线评估

2、第二道门：影子运行

3、第三道门：建议与审批

4、第四道门：受限自动化

四、Harvester + Tuner：把日常反馈变成受控改进

（一）三角色闭环解决了什么问题

1、Initial Agent 负责工作，不负责自我辩护

2、Harvester 负责把人类信号结构化

3、Tuner 负责提出修改，不直接改生产

（二）闭环要防止“把偏好放大成错误”

1、反馈偏差会被系统性复制

2、改进必须能够被反驳

五、从案例清单看 Agent 的最佳落点

（一）法律流程中的七类生产任务

1、代码审查：可验证、可回退、反馈密集

2、EvidenceChain 文件交付：跨系统但成功标准清楚

3、eFiling 拒绝诊断：高价值解释，而非替代法律判断

4、案件核验：环境事实必须实时取得

5、律师排班：多方沟通中的半结构化协调

6、AR Remittance：结构化产物加人类确认

7、Charvis 合规审查：一致率不等于安全率

（二）判断一个流程是否值得 Agent 化

1、五个正向信号

2、五个反向信号

3、选择最小充分自动化

六、从 50 个 Agent 到一套运行体系：六本账

（一）资产账与责任账

1、资产账：公司到底拥有哪些 Agent

2、责任账：谁对结果、运行和风险负责

（二）权限账与版本账

1、权限账：能看什么、能做什么

2、版本账：一次结果由哪个行为版本产生

（三）运行账与价值账

1、运行账：每次运行发生了什么

2、价值账：这次运行创造了什么

七、经济账：为什么“调用更便宜”不等于“业务更划算”

（一）建立可比较的单位经济模型

1、完整成本不能只算模型费用

2、用任务为单位，而不是用会话为单位

（二）优化顺序决定是否会走出 J 曲线

1、先删不必要的 Agent 步骤

2、再做模型分层与上下文治理

3、最后扩大自治和覆盖率

八、案例的边界：哪些内容不能被成功故事遮蔽

（一）数字需要被正确解读

1、“50+ Agent”不是成熟度指标

2、“98% 一致”缺少分母和误差结构

3、“最高约 50% 成本下降”不是普遍 ROI

（二）安全与合规风险会随工具连接放大

1、间接 Prompt Injection

2、记忆污染和跨任务泄漏

3、多 Agent 级联失败

（三）组织风险往往先于模型风险

1、审批疲劳

2、责任稀释

3、流程被过早固化

九、可复制的落地方法：一套 90 天路径

（一）第 1—30 天：建立最小治理底座

1、选三个任务，不选三个部门

2、建立最小 Agent 清单和模板

3、只允许影子或建议模式

（二）第 31—60 天：把反馈变成评估

1、定义分层指标

2、上线 Harvester，延后 Tuner 自动提案

3、建立 PR 发布门槛

（三）第 61—90 天：开放受限自治并管理组合

1、只给稳定动作自治权

2、建立 Agent 投资组合看板

3、训练“业务构建者”，而不只是 Prompt 用户

十、进一步的思考：Agent 平台正在成为新的组织操作系统

（一）管理对象从应用转向“决策—行动单元”

（二）最有价值的资产可能是“可执行的组织知识”

（三）真正的护城河不是 Agent 数量，而是反馈质量

十一、结语：从“谁都能做 Agent”走向“公司能够治理 Agent”

可参考文章与资料

干货分享，感谢您的阅读！

ABC Legal 的价值不在于“做出了 50 多个 Agent”这个数量，而在于它把 Agent 从员工电脑上的个人脚本，迁移成了具有所有者、版本、权限、评估、成本和退出机制的公司资产。

本文在通读 Anthropic 案例原文的基础上，重构其管理逻辑，并进一步提出一套适用于企业落地的“六本账、四道门、三条反馈回路”方法。文中涉及 50+、约 310 人、98% 一致率、部分任务成本最高约下降 50% 等数字，均为 ABC Legal 或 Anthropic 案例披露口径，不代表独立审计结论，也不应直接外推到其他组织。

ABC Legal 案例关键数字与真正的管理转折。资料来源：Anthropic 案例文章；本图为重新设计。

一、当自动化从个人效率工具变成公司资产

（一）一个成功得太快的问题

从“谁做谁运行”到“统一登记、部署、监控和计费”。

1、业务人员开始自己造工具

ABC Legal 是一家面向美国法律流程的服务公司，业务涉及诉讼文书送达、电子立案、出庭律师协调及其周边运营。法律流程服务有几个天然特征：案件量大、时限严格、规则分散、文档密集、跨系统协作频繁，而且许多错误不会立刻显现，却可能在后续形成合规、时效或客户体验问题。这类环境很适合自动化，因为大量工作具有重复结构；也很难自动化，因为每个州、法院、案件和客户又可能存在例外。

2026 年，ABC Legal 向约 1,100 名员工开放 Claude Enterprise。 adoption 并不是由一个中央 AI 团队逐项推动的，反而是服务送达、电子立案、出庭协调、营销、合规、财务等部门的员工自行寻找痛点、连接工具、创建自动化。对管理层而言，这是一种理想的“需求侧创新”：最了解流程的人直接把隐性知识表达成指令，开发队列不再成为唯一瓶颈。

但去中心化创新很快制造了第二个问题。早期 Agent 主要以定时任务或本地例程运行在个人电脑上。一个 Agent 能否按时启动，取决于电脑是否在线；Prompt 改过什么、何时改的、为什么改，可能只存在于个人记忆；Credentials 如何保存、运行失败由谁响应、调用花了多少钱，也缺少统一视图。单个自动化看起来提高了效率，整体却形成了新的“影子生产系统”。

2、真正的风险不是 Agent 会不会回答，而是公司看不见它

传统软件一旦进入生产，组织通常会要求代码仓库、发布流程、监控告警、权限控制、审计记录和责任人。可当同样会读数据、调用工具、发消息甚至修改业务记录的能力被包装成“一个 Prompt”时，人们容易把它误判为轻量内容，而不是生产软件。

这正是零散自动化的危险之处：它把执行能力藏在看似无害的自然语言背后。Agent 失败时，可能不是返回一段错误文字，而是没有发送客户文件、遗漏某项核验、错误分类一笔款项，或者在不合适的时间向外部人员发出消息。公司如果连 Agent 清单都没有，就无法回答最基本的治理问题：今天有哪些自动化在代表公司行动？它们访问了哪些数据？谁批准了当前版本？失败后谁接手？因此，ABC Legal 的关键转折不是换了一个更强的模型，而是把 Agent 迁移到统一的 Managed Agents 运行方式：共同的部署结构、共享工作区、集中审计与计费、云端常驻运行。到 2026 年 7 月，案例披露其已有 50 多个生产 Agent，约 310 名员工日常使用 Claude。数字说明了规模，但规模背后的制度化才是更重要的结果。

（二）企业真正需要管理的是“行动权”

1、聊天工具与生产 Agent 的边界

企业使用大模型大致可以分成三层。第一层是个人辅助，例如写作、总结、头脑风暴，输出主要由人消费；第二层是工作流，步骤相对固定，模型在局部负责分类、抽取或生成；第三层才是 Agent，它能够根据环境反馈规划下一步、调用工具、维持上下文并采取行动。越往后，输出离真实业务状态越近，错误的传播半径也越大。

Anthropic 在“Building Effective AI Agents”中建议，只有当简单方案确实不足时才增加 Agent 复杂度，因为自主系统会带来更高成本和误差累积风险。这个判断与 ABC Legal 的实践相互印证：并不是所有流程都应该被 Agent 化，固定、确定、可用规则表达的工作，传统脚本或工作流往往更稳定、更便宜；只有步骤难以预先穷举、需要在环境中获取反馈、又有清晰成功标准的任务，Agent 才显示出独特价值。

2、把 Agent 看成“受约束的数字岗位”

比“数字员工”更准确的说法，是“受约束的数字岗位”。一个岗位不是一个聪明个体，而是一组职责边界：能看什么、能做什么、何时升级、如何交接、怎样考核。企业管理 Agent 也应从同样的问题出发。

每个生产 Agent 至少需要回答七个问题：它只有一个明确任务吗？业务所有者是谁？输入和输出的契约是什么？可以调用哪些工具、以什么权限调用？哪些动作必须由人批准？怎样判断这次运行成功？何时暂停、回滚或退役？如果这些问题没有被写进配置、文档和监控，Agent 就仍然是一段“可运行的愿望”，而不是可管理的生产能力。

二、Agent as Code：把自然语言能力纳入软件工程纪律

（一）为什么“代码化”比“写好 Prompt”更重要

1、Prompt 只是 Agent 的一个部件

ABC Legal 将 Prompt、Tool 列表、Schedule、Credentials、Memory 和 Config 放入 Git 仓库。这个做法被概括为 Agent as Code，但它的含义不是要求业务人员成为程序员，而是把影响 Agent 行为的关键要素变成结构化、可比较、可审批的文本资产。

一个 Agent 的输出会同时受到多种因素影响：系统指令定义角色与约束，工具定义行动空间，触发器决定何时运行，凭证决定它能触达什么资源，记忆决定它携带什么历史，模型与参数影响推理和成本，外部规则库决定事实基础。如果只版本化 Prompt，其余部分仍可在后台漂移，组织就无法重现“为什么上周正确、今天错误”。

真正的 Agent as Code 应把“行为面”整体纳入版本控制。每次变更形成 diff，审阅者可以看到新开了哪项权限、修改了哪条退出条件、增加了哪个数据源；合并后触发部署；出现问题时可回滚到已知版本；审计时可以把一次业务结果追溯到当时的配置、模型、工具和规则版本。

Agent 不是单一 Prompt，而是由指令、工具、触发、凭证、记忆、模型和运行文档共同定义的行为单元。

2、Pull Request 是控制面，不只是开发流程

在 ABC Legal，生产 Agent 的变更必须通过 Pull Request。PR 的价值在于把模糊的“我想让它更聪明”转化成可审查的具体变化：新增了什么规则？删除了什么限制？哪些测试证明它更好？成本是否改变？是否需要更高权限？

这使 PR 从代码协作工具变成组织的决策控制面。它提供逐行评论、审批人、不可变历史、合并状态和回滚点，并能与自动测试、评估集、安全扫描和部署流水线连接。尤其当 Tuner 也能提出修改时，PR 把“AI 改 AI”限制为“AI 提案、人类授权”，避免反馈回路直接改写生产行为。

当然，PR 不是天然安全。若审批只是形式化点击，审阅者看不懂配置，或同一人既提出又批准高风险变更，那么 Git 只记录了过程，没有真正降低风险。有效的控制面需要明确审阅责任：业务所有者确认规则意图，技术或平台人员确认工具和部署，安全/合规人员按风险参与，评估结果作为合并门槛，而不是附件。

（二）标准模板如何释放非技术人员的生产力

1、把“空白页”变成“有护栏的起跑线”

ABC Legal 用约一周制作了两类启动模板：事件驱动 Agent 和定时 Agent。每个 Agent 采用标准目录，包含 JSON 配置、Markdown 系统 Prompt、部署脚本和运行文档。模板减少的并不只是编码量，更重要的是决策量。业务人员不用重新发明凭证管理、日志字段、失败重试、所有者标记和部署方式，只需在已批准的结构中表达业务任务。

这是一种平台工程思路：中央团队不包办每个业务自动化，而是提供“铺好的道路”。道路内置安全边界、观察能力和交付规范，业务构建者负责本领域规则。结果是速度与治理不再完全对立——标准化做得越好，自助式创新越容易被纳入统一管理。

2、真正的学习障碍是新的协作语法

案例中，15 人指导委员会成员来自财务、营销、运营和开发等部门，并非软件开发者。他们在一周内做出可运行的 Agent，随后回到团队培训他人。困难反而集中在 Git、Repository 和 Pull Request 这些概念上。

这个细节很重要。自然语言降低了表达业务逻辑的门槛，却没有自动消除生产治理的门槛。组织需要教授的不只是“如何提示模型”，而是如何提出变更、阅读 diff、描述测试样例、处理冲突、理解审批和回滚。换言之，AI 素养正在从 Prompt 技巧转向“可审计协作素养”。

对多数企业，理想界面未必要求每个员工直接使用命令行。可以在底层保留 Git 和 PR，在上层提供表单、向导、可视化 diff 和受控模板，让业务人员仍然遵守版本化流程。关键不是强迫所有人像工程师一样操作，而是不能因界面简化而丢掉工程纪律。

三、渐进式自主权：让权限跟着证据增长

（一）“先建议、后执行”不是保守，而是数据策略

1、建议模式同时完成三件事

ABC Legal 的新 Agent 通常先以人机协作方式运行：它分析任务并给出建议，由员工接受或拒绝。表面上看，这降低了自动化率；实际上，它同时完成三项基础建设。

第一，保护业务。Agent 在尚未证明可靠时不直接产生不可逆后果。第二，建立基线。系统可以比较 Agent 建议与人类最终决策，识别哪些任务类型稳定、哪些例外频发。第三，生产标签。接受、拒绝、修改以及理由，都会成为后续评估和调优所需的数据。

因此，人类在环不应被设计成永久的人工审批税，也不能只是一个没有上下文的“确认”按钮。审批界面应显示任务、证据、拟采取动作、影响范围和可撤销性；同时尽量捕捉拒绝原因。只有这样，人工操作才会从成本转化为可信度资产。

2、自主权必须按动作而不是按 Agent 一次性授予

一个 Agent 可能既能读取案件信息，又能修改状态、发外部邮件、上传文件。把它整体标记为“自动”或“人工审批”过于粗糙。更合理的做法是按动作风险分级：只读查询可自动，内部草稿可自动生成，外部发送需确认，资金、删除、权限变更等关键动作需要更强审批甚至双人复核。

OWASP 的 AI Agent Security Cheat Sheet 同样强调最小权限、对高影响动作进行独立验证、把批准绑定到具体参数、保留审计记录并在失败时默认关闭。由此可见，“Earned Autonomy”不只是管理口号，它需要被落实为工具级授权、动作级策略和可撤销的运行状态。

自主权按证据和动作风险逐级开放；即使进入自动执行，也要持续监测并允许降级。

（二）四道门：从影子运行到自动执行

1、第一道门：离线评估

在上线前，用历史样本、合成边界案例和已知失败案例测试 Agent。评估不应只问“答案像不像”，而要分别测量事实正确性、规则适用性、工具选择、参数准确性、拒答与升级、敏感信息处理、时延和单次成本。对于 eFiling 拒绝诊断一类任务，还要按法院、州、文书类型和拒绝原因分层，避免总体平均分掩盖小样本高风险错误。

最低要求：评估集有版本；每个样本有期望结果或可复核判据；失败可以归因到 Prompt、工具、数据、规则或权限；发布门槛提前定义，而不是看到结果后再调整标准。

2、第二道门：影子运行

Agent 在真实流量上运行，但不影响业务结果。它的建议与现行人工流程并行记录，用来估计覆盖率、准确率、异常类型和潜在节省。影子运行能发现离线数据无法复制的问题，例如第三方网站变化、邮件格式漂移、凭证过期、上游字段缺失和峰值负载。

关键指标：除了“与人工一致率”，还应观察无法处理率、错误自信率、升级率、人工复核时长、误报与漏报代价，以及不同业务切片的表现差异。

3、第三道门：建议与审批

当 Agent 在真实环境中达到基本稳定性，可把建议嵌入员工工作界面。此时重点是验证“人在看见充分证据后，能否高质量地批准”。如果审批者长期无差别接受，说明界面可能诱发自动化偏见；如果员工必须重新完成全部工作才能判断，说明 Agent 没有真正节省认知成本。

4、第四道门：受限自动化

只有在特定任务、特定数据范围和特定动作上持续达标，才开放自动执行。自动化应包含预算上限、调用频率、最大迭代、超时、熔断、异常升级和回滚机制。进入第四级并非毕业，而是进入更严格的生产监测阶段：数据分布、外部规则或模型版本发生变化时，系统应能自动降级回建议模式。

四、Harvester + Tuner：把日常反馈变成受控改进

（一）三角色闭环解决了什么问题

1、Initial Agent 负责工作，不负责自我辩护

Initial Agent 在事件发生时执行任务，记录输入、证据、工具调用、输出和结果。它不应一边做决定，一边决定哪些反馈值得保留，否则容易产生选择性记录。工作 Agent 的首要职责是完成单一任务并生成可追踪轨迹。

2、Harvester 负责把人类信号结构化

ABC Legal 的 Agent 将结果发到 Slack，员工通过线程回复或 Emoji 反馈。Harvester 按小时或每天收集这些信号，并转化成带标签的数据点。这个角色看似简单，却决定了反馈数据是否可用。

Emoji 不是天然的真值。“赞”可能表示结论正确，也可能只是已读；沉默可能表示默认接受，也可能表示没人查看。Harvester 因此需要保留上下文：谁反馈、反馈针对哪项输出、是否发生后续修改、最终业务结果是什么。对于高风险任务，弱反馈只能作为线索，不能直接等同于正确标签。

3、Tuner 负责提出修改，不直接改生产

Tuner 每周汇总反馈，寻找重复失败模式，提出 Prompt 或 Config 调整，并创建 PR。它不修改模型权重，也不能直接部署。这样，自动改进被限定为一个可解释的配置变更过程，审阅者能看到修改前后差异、支持证据和评估结果。

工作结果经人类反馈形成标签，Tuner 只提交变更提案；人类审批是进入生产的边界。

（二）闭环要防止“把偏好放大成错误”

1、反馈偏差会被系统性复制

如果参与反馈的员工只代表某个班次、地区或资历层级，Tuner 可能把局部偏好写成全局规则；如果审批者更倾向于接受表达流畅的建议，语言风格会被误当成业务正确性；如果只采集失败案例，系统可能过度收缩；如果只采集点赞，又会高估可靠性。

因此，Harvester 产出的不是“训练真相”，而是待验证证据。企业需要对反馈来源、样本覆盖、冲突标签、时间窗口和业务结果做质量控制。对重大规则修改，最好保留一个不参与调优的验证集，避免系统只是在记住最近的抱怨。

2、改进必须能够被反驳

一个合格的 Tuner PR 应至少包含：问题描述、受影响样本、拟修改项、预期改善、可能副作用、离线评估对比、成本变化、回滚条件。审阅者不仅要判断“新版本是否更好”，还要判断“在哪些切片更好、在哪些切片更差”。

这使 Agent 改进从经验式 Prompt 修改，转向小型实验管理。每次变更都是一个可以被证伪的假设，而不是一次不可解释的“优化”。长期看，企业积累的核心资产不是某一句神奇 Prompt，而是失败案例、评估集、变更历史和判断标准。

五、从案例清单看 Agent 的最佳落点

（一）法律流程中的七类生产任务

1、代码审查：可验证、可回退、反馈密集

ABC Legal 的 AI Code Reviewer 检查多个代码库的 Pull Request，寻找安全缺陷、性能退化和误提交的 Credentials。代码审查适合 Agent 的原因并非代码“容易”，而是环境能提供高质量反馈：静态检查、测试结果、diff、工程师评论和后续故障都可成为证据；最终合并仍由人控制。

2、EvidenceChain 文件交付：跨系统但成功标准清楚

该 Agent 根据报告筛选任务，逐一取得 PDF，并按日交付到客户 FTP。它跨越数据库、浏览器和文件传输，但成功标准非常明确：正确的文件、正确的客户、正确的时间、可验证的传输结果。案例称，一名此前没有自动化经验的客户经理通过描述需求，在约一小时内完成构建。这个速度值得关注，但企业复制时仍需补齐权限、异常重试、文件完整性和客户数据隔离。

3、eFiling 拒绝诊断：高价值解释，而非替代法律判断

法院拒绝电子材料后，Agent 读取任务详情、查询法院规则，并在约一分钟内把诊断发到 Slack。其价值在于快速缩小问题空间，让员工不用从零翻查规则。这里最重要的控制不是让模型“更自信”，而是显示依据、规则版本和不确定性，并在规则冲突或时限风险较高时升级给人。

4、案件核验：环境事实必须实时取得

核验 Agent 访问法院网站，确认案件或听证是否正确登记、日期是否存在，并据此调整任务、标注司法辖区和时效信息。这类工作体现 Agent 与普通文本生成的根本区别：它必须从环境取得 ground truth，不能只凭模型记忆。网站结构变化、验证码、数据延迟和同名案件都会成为生产风险，因此浏览器行为、证据快照和失败分流十分关键。

5、律师排班：多方沟通中的半结构化协调

Attorney Coverage Agent 查询律师可用时间、发送邮件、读取关于时间和报价的回复，再交给协调员确认。它处理的是半结构化、多轮、跨主体任务，固定脚本很难覆盖所有表达方式；但最终确认保留在人手中，限制了错误承诺和价格误读的影响。

6、AR Remittance：结构化产物加人类确认

财务 Agent 解析汇款邮件，生成 NetSuite 可使用的付款应用文件，发送到 Slack 供一键批准后再导入。这个模式值得推广：模型负责理解非结构化输入和生成结构化草稿，确定性校验负责金额、客户、发票号与总额平衡，人类批准负责承担高影响动作。把三者混在一个端到端 Prompt 中，反而会降低可控性。

7、Charvis 合规审查：一致率不等于安全率

案例称，Charvis 对已完成服务任务的判断与人工合规团队约 98% 一致。这个数字说明系统可能已达到很高的实用性，但不能单独证明其可全面自治。假设剩余 2% 集中在高风险案件、少数司法辖区或时效边缘，一致率仍可能掩盖重大损失。评估必须进一步拆分：是 Agent 错、人工错，还是规则本身存在解释空间？误报和漏报的代价是否对称？高风险切片是否另设阈值？

案例任务从“分析建议”延伸到“跨系统执行”，越靠近外部行动与资金记录，越需要确定性校验和人工授权。

（二）判断一个流程是否值得 Agent 化

1、五个正向信号

适合 Agent 的任务通常同时具备若干特征：输入高度依赖非结构化文本或网页；步骤数量会随情境变化；需要调用多个系统；成功结果能够被外部事实验证；人类可以在关键点提供有信息量的反馈。法律拒绝诊断、律师协调和跨系统文件交付都符合这些条件。

2、五个反向信号

不适合的信号同样清晰：规则固定且传统代码更可靠；任务发生频率极低，构建和维护成本无法摊薄；失败后果极高但无法充分验证；数据权限无法最小化；没有明确所有者或没人愿意处理异常。此时“能做”不等于“值得做”。

3、选择最小充分自动化

企业常见误区是把“全自动”当作成熟度最高。实际上，更好的目标是最小充分自动化：只自动化能够稳定创造价值的环节，把判断、例外和责任保留在最合适的位置。一个只生成 NetSuite 导入草稿、由确定性规则验算并让财务确认的系统，可能比完全自动入账更有商业价值，因为它节省了主要劳动，又没有承担不必要的尾部风险。

六、从 50 个 Agent 到一套运行体系：六本账

（一）资产账与责任账

1、资产账：公司到底拥有哪些 Agent

最小 Agent 注册表应包含唯一 ID、名称、单一任务、业务部门、触发方式、生产状态、仓库路径、当前版本、使用模型、工具清单、数据分类、成本中心和最近运行时间。没有资产账，监控和安全只能是偶然的。

注册表还应记录依赖关系。一个 Agent 可能依赖第三方网站、内部 API、知识库、消息渠道和下游导入器。依赖变化时，平台可以定位受影响 Agent，而不是等待业务报错。

2、责任账：谁对结果、运行和风险负责

每个 Agent 至少有业务 Owner 和技术/平台 Owner。业务 Owner 定义成功标准、规则含义和例外处理；平台 Owner 负责部署、观测、凭证、可靠性和回滚。高风险 Agent 还需数据、安全或合规责任人参与。

“Agent 有名字”并不等于“Agent 有责任人”。责任账必须连接到值班、升级和退役流程：Owner 离职或转岗时自动触发交接；长时间无人维护的 Agent 不应继续拥有生产权限。

（二）权限账与版本账

1、权限账：能看什么、能做什么

权限账要下沉到工具和资源范围。例如，不是笼统地写“可访问邮箱”，而是只能读取特定共享邮箱、不能发送；不是“可访问数据库”，而是只读特定视图、限定租户和字段；不是“可用浏览器”，而是限定域名、下载类型和上传目标。

Credentials 不应进入 Git 明文。仓库保存凭证引用、权限声明和轮换策略，真正秘密由凭证库托管。权限变更应像代码变更一样经过审查，并能在异常时集中吊销。

2、版本账：一次结果由哪个行为版本产生

除了 Prompt 版本，还应记录 Config、工具定义、规则库、模型、评估集和部署时间。模型服务可能升级，外部规则可能更新，工具 API 也可能改变；如果运行记录无法指向完整版本组合，就难以复现和归责。

版本账还应明确兼容性：某个 Prompt 是否只在特定工具 schema 下测试？模型替换是否需要重新评估？规则库更新是否会使历史标签失效？这些问题决定了回滚是否真的“简单”。

（三）运行账与价值账

1、运行账：每次运行发生了什么

运行账包含触发时间、输入引用、步骤、工具调用、延迟、重试、输出、审批、执行结果、错误类型和最终业务状态。日志需要结构化，也要经过敏感信息脱敏。记录越多不一定越安全；如果日志复制了客户隐私、凭证或完整文书，就会制造新的数据资产风险。

监控不应只盯“成功/失败”。还要观察调用次数异常、成本突增、工具权限拒绝、循环接近上限、审批绕过尝试、数据分布变化和人工推翻率上升。OWASP 将可观测性、成本监测、异常检测和审计轨迹列为 Agent 安全的重要控制，这与 ABC Legal 统一审计和计费的经验一致。

2、价值账：这次运行创造了什么

ABC Legal 让 Agent 每次运行把价值以时间和金额回报到数据仓库，并跟踪价值/成本效率比。这个思路优于只看 Token：Token 是资源消耗，不是业务结果。真正的分子可以是节省工时、缩短周期、减少返工、提高回收、降低错误或增加转化；分母则包括模型、工具、平台、人工复核、维护和失败处置。

新 Agent 常在早期“水下”：评估、复核和大模型成本较高；经过路由、模型分层、Prompt 精简和流程稳定后才可能转正。曲线为概念示意，不代表 ABC Legal 实际财务数据。

七、经济账：为什么“调用更便宜”不等于“业务更划算”

（一）建立可比较的单位经济模型

1、完整成本不能只算模型费用

一个 Agent 的月度总成本至少包括：模型推理、外部工具或数据、平台运行、工程维护、业务复核、异常处理、安全与合规，以及失败带来的预期损失。前几项容易进入账单，后几项常被隐藏在员工时间和风险预算里。

可以用一个简单框架表达：

净价值 = 已实现业务收益 −（推理成本 + 工具成本 + 复核成本 + 维护成本 + 预期错误损失）。

其中“已实现”很关键。Agent 生成了一条建议，不等于节省已经发生；只有员工实际减少了操作、周期确实缩短、错误确实减少，价值才应入账。反过来，若员工仍需完整重做一遍才能批准，表面自动化可能只是把工作从“执行”搬到了“核验”。

2、用任务为单位，而不是用会话为单位

适合比较的单位是一个可交付任务，例如一次拒绝原因诊断、一份汇款文件、一个完成案件审查。对每类任务记录人工基线时间、Agent 运行成本、复核时间、成功率和返工率，就能判断是否值得继续。

若只按团队汇总总 Token，管理层会看到成本，却看不到哪个 Agent 创造价值；若只报告节省工时，又容易忽略质量与风险。把价值和成本绑定到 Agent、版本、用例和单次运行，才能形成真正的投资组合管理。

（二）优化顺序决定是否会走出 J 曲线

1、先删不必要的 Agent 步骤

最有效的优化通常不是立即切换到更便宜模型，而是确认哪些步骤根本不需要模型。确定性字段校验、金额求和、格式转换、权限检查和重复检测应该交给代码；模型只处理语义理解、例外判断和开放式规划。

2、再做模型分层与上下文治理

简单高频任务可路由到更快、更便宜的模型，复杂低频任务使用更强模型；只有异常才升级。上下文也应按需获取，避免每次把整个知识库、长邮件线程或历史记忆塞入 Prompt。记忆设置保留范围、过期时间和敏感数据过滤，既降成本，也减少错误上下文污染。

3、最后扩大自治和覆盖率

只有在单位经济和风险指标稳定后，扩大处理量、覆盖更多场景或减少人工审批才有意义。否则，自动化只是把一个尚未验证的负收益流程放大。ABC Legal 案例中提到使用量增长而成本在后期下降，说明优化与规模可以同时发生；但这依赖精细计量，而不是模型价格自然下降。

八、案例的边界：哪些内容不能被成功故事遮蔽

（一）数字需要被正确解读

1、“50+ Agent”不是成熟度指标

数量只能说明采用广度。五十个单一任务、清晰 Owner、持续使用且单位经济为正的 Agent，当然有意义；五十个低频、无人维护、权限过宽的 Agent，则是五十个风险点。更有用的指标是活跃率、成功率、人工推翻率、异常恢复时间、版本新鲜度、正净价值比例和退役速度。

2、“98% 一致”缺少分母和误差结构

Charvis 的约 98% 一致率来自案例方自报。没有样本量、时间窗口、类别分布、人工基准可靠性以及误报漏报拆分，读者不能把它等同于 98% 准确率，更不能直接推断剩余 2% 的风险。专业评估应报告置信区间和关键切片，并对高损失错误单列。

3、“最高约 50% 成本下降”不是普遍 ROI

原文说的是某些 Agent 覆盖的人类任务成本最高约下降 50%，且在深度优化前。这里至少有三个限定：是部分任务，不是全公司；是任务成本，不一定包含全部平台与治理成本；“最高”不是平均数。企业应把这个数字视为可探索的上限信号，而非预算承诺。

（二）安全与合规风险会随工具连接放大

1、间接 Prompt Injection

能读取网页、邮件和文档的 Agent 会接触不可信内容。恶意指令可能藏在法院网站、附件、邮件签名或 PDF 中，诱使 Agent 忽略系统规则、调用工具或泄露数据。防护不能只靠一句“不要听外部指令”，而应把外部内容标记为数据、限制工具权限、验证输出、隔离敏感上下文，并对高影响动作独立授权。

2、记忆污染和跨任务泄漏

如果 Agent 把未经验证的内容写入长期记忆，错误或恶意信息会影响后续运行；如果不同客户、案件或用户共享上下文，还可能出现数据串扰。记忆应具备来源、作用域、过期、大小限制和完整性检查，敏感信息持久化前需要过滤。

3、多 Agent 级联失败

Harvester、Tuner、部署器之间的分工降低了直接自改风险，也创造了链式依赖。错误标签可能诱发错误 PR，错误审批可能进入生产，部署器再把配置推送给大量任务。多 Agent 系统不能只验证每个节点，还要验证消息身份、schema、授权边界、重放保护和全链路停止条件。

六本账解决“看得见、说得清、追得回、算得出”，四道门控制自主权扩张。

（三）组织风险往往先于模型风险

1、审批疲劳

当 Agent 每天产生大量低质量建议，员工会形成机械批准，Human-in-the-loop 变成形式。需要通过风险分层、抽样复核、可解释证据和审批质量指标，减少无意义点击。

2、责任稀释

“这是 AI 做的”不能成为事故解释。Agent 的业务 Owner 对规则与结果负责，平台团队对运行控制负责，审批者对具体高影响动作负责。责任边界应在上线前写清，而不是事故后寻找。

3、流程被过早固化

把业务规则写进仓库提高了可管理性，也可能把历史习惯固化成机器执行。X-as-code 的前提是先确认规则值得保留，并建立例外与申诉渠道。否则，Agent 只是以更高速度复制旧流程的不合理之处。

九、可复制的落地方法：一套 90 天路径

（一）第 1—30 天：建立最小治理底座

1、选三个任务，不选三个部门

优先选择任务边界清楚、频率足够、成功可验证、失败可恢复的用例。一个来自财务、一个来自运营、一个来自技术并不重要；重要的是三者能否代表不同动作风险，并产生可比较的数据。

2、建立最小 Agent 清单和模板

定义统一目录、Owner 字段、工具权限、触发器、日志 schema、评估集位置、成本中心、升级联系人和退役条件。提供事件驱动与定时两类模板，在模板中默认启用最小权限、超时、重试、最大迭代和审计。

3、只允许影子或建议模式

首月不追求全自动。收集人工基线、异常类型和真实反馈，验证日志能否重放一次运行，凭证能否集中吊销，故障能否由非构建者接手。

（二）第 31—60 天：把反馈变成评估

1、定义分层指标

为每个任务定义质量、效率、风险、体验和成本指标；按地区、客户、案件类型、输入来源等关键维度切片。将拒绝与修改原因结构化，而不是只收集赞踩。

2、上线 Harvester，延后 Tuner 自动提案

先验证反馈采集的准确性和覆盖率，再让 Tuner 生成变更建议。若标签本身不可靠，自动调优只会更快地把噪声写入生产规则。

3、建立 PR 发布门槛

每个变更必须附评估对比、受影响范围、权限变化、成本变化和回滚条件。高风险工具变更要求额外审批。部署后进行小流量或限定范围验证。

（三）第 61—90 天：开放受限自治并管理组合

1、只给稳定动作自治权

将“读取—分析—草拟—写入—外发—不可逆”拆分，分别授权。优先自动化可验证、幂等、可撤销的动作；对外沟通、财务和删除继续保持强审批。

2、建立 Agent 投资组合看板

看板不只显示运行次数，还应显示净价值、成功率、人工推翻率、异常恢复时间、成本趋势、版本年龄和权限等级。把 Agent 分为扩大、优化、观察、暂停、退役五类，形成定期组合评审。

3、训练“业务构建者”，而不只是 Prompt 用户

培训内容包括流程拆解、数据边界、测试样例、PR 协作、风险升级和价值计算。业务构建者不需要掌握完整软件开发，但必须理解自己正在创建会影响生产状态的系统。

先建账和留证，再闭环评估，最后开放受限自治；每一阶段都以可退出为前提。

十、进一步的思考：Agent 平台正在成为新的组织操作系统

（一）管理对象从应用转向“决策—行动单元”

传统企业软件以应用为边界：CRM、ERP、工单、邮箱各自承载流程。Agent 会跨越这些边界，为一个目标临时组合信息和动作。因此，治理单位不能只停留在应用访问权，而要下沉到“谁在什么条件下，基于哪些证据，对哪个对象采取什么动作”。

这会推动企业建立更细粒度的政策服务：工具调用前验证身份与范围，关键参数与审批绑定，运行中监测异常，执行后写入可追溯结果。未来的 Agent 平台，不只是模型入口，更像一层连接身份、数据、流程、评估和财务的组织操作系统。

（二）最有价值的资产可能是“可执行的组织知识”

ABC Legal 把 Prompt、路由规则、通知模板和业务配置写入仓库，实际上是在把散落于员工经验、后台表单和口头约定中的知识，转成可以审阅、测试和演进的文本。所谓 X-as-code，不应理解为万物都要由工程师编码，而是把重要规则变成有版本、有责任、有证据的组织资产。

当规则可比较，企业才能知道一次改变究竟改善了什么；当例外可记录，知识才能从个体经验变成共享能力；当 Agent 的每次运行都回传结果，流程优化才从年度项目变成持续系统。

（三）真正的护城河不是 Agent 数量，而是反馈质量

模型、框架和连接器会快速商品化。单个 Prompt 也很容易复制。更难复制的是一个组织长期积累的真实失败样本、清晰评估标准、高质量人类反馈、动作级权限策略和可信变更流程。

因此，企业应谨慎对待“自我改进”这个词。系统不会因为收集了更多 Emoji 就自然变聪明；只有当反馈被正确解释、变更可以被反驳、结果经过独立评估、权限由人类授予时，反馈才会变成能力。否则，闭环只是让偏差循环得更快。

十一、结语：从“谁都能做 Agent”走向“公司能够治理 Agent”

ABC Legal 案例最值得借鉴的，不是某个具体 Agent，也不是某一款 Managed Agents 产品，而是一套次序：先让业务人员发现机会，再把生产能力迁入统一运行环境；先把行为要素版本化，再开放更大自主权；先收集真实反馈，再让系统提出改进；先算清单位经济，再扩大覆盖范围。

这套次序化解了企业 AI 落地中最常见的伪矛盾。治理不一定意味着中央团队包办，标准化也不一定压制创新。只要平台提供有护栏的模板、清晰的变更控制和可观察的运行底座，业务人员可以成为构建者，中央团队则从“代写每个自动化”转向“设计安全的生产道路”。

最终，成熟的 Agent 组织不会以“完全无人”作为目标。它追求的是：机器承担可验证、可恢复、可计量的执行，人类保留价值判断、例外裁决和责任；自主权由证据赢得，也能因风险信号被收回。管理的从来不是 50 个 Prompt，而是一套新的数字劳动力制度。

可参考文章与资料

1. Anthropic：How ABC Legal turned every employee into a builder with Claude Managed Agents（案例原文，2026 年 8 月 17 日）

2. Anthropic：Building Effective AI Agents（Agent 与工作流的设计原则）

3. NIST：Artificial Intelligence Risk Management Framework — Generative AI Profile（生成式 AI 风险管理框架）

4. OWASP：AI Agent Security Cheat Sheet（工具权限、Prompt Injection、记忆、人类审批与可观测性）

5. Claude Platform Docs：Managed Agents — Agent Setup（产品配置参考）