50+ 个 Agent 上线、310 人在用：ABC Legal 最值得抄的不是 Claude，而是把 Agent 当软件管理

昨天 Anthropic 公布了一个我觉得很值得企业团队认真看的案例。

ABC Legal 是一家美国法律文书服务公司。今年早些时候，他们把 Claude Enterprise 推给了 1,100 名员工。

到 2026 年 7 月，Anthropic 公布的几个数字是：

50+ Managed Agents 已在生产运行
约 310 名员工在各部门日常使用 Claude
部分 Agent 覆盖的人工任务成本最高下降约 50%

这些数字当然很吸引人。

但我看完整个案例以后，最想抄的不是“用了 Claude Managed Agents”。

而是他们做了一个非常工程化、甚至有点朴素的决定：

把每一个 Agent 当成软件。

不是存在某个人电脑里的定时任务。

不是 Chat 里保存的一段 Prompt。

也不是一个只有创建者才知道怎么改的自动化。

而是：

Git
PR
Owner
Version
Audit
Rollback

这才是这个案例最有价值的地方。

他们早期也走过“放在个人电脑上跑”的路

Anthropic 的案例里写得很具体。

ABC Legal 早期的 Agent 会作为 scheduled task 跑在员工自己的桌面电脑上。

这很符合很多公司的自然演进：

某个员工发现一个重复工作
↓
自己写一个脚本/Prompt
↓
本机定时跑
↓
慢慢变成业务依赖

一开始很好用。

但当 Agent 多起来，CTO 面临的问题变成：

公司到底有多少Agent？
昨晚哪些跑了？
哪个失败？
花了多少钱？
谁负责？
Prompt谁改过？

这就是从“个人自动化”到“组织软件”的分界线。

ABC Legal 做的第一件关键事：Agent as Code

他们把 Agent 的这些内容都放进 Git：

Prompt
Tool List
Schedule
Credential Configuration
Memory Configuration

每个 Agent 自己一个目录。

Anthropic 案例描述的标准结构包括：

JSON config
System Prompt in Markdown
Deployment scripts
Operational documentation

然后规定：

任何Agent变化
都必须通过Pull Request

这一步非常重要。

因为 PR 一下子带来了：

• 版本历史；
• Code Review；
• 审批；
• 回滚；
• Audit Trail。

Agent 治理突然从“AI问题”变成了成熟的软件工程问题。

他们甚至让非程序员学会了 PR

这个案例里有一个细节很真实。

ABC Legal 拉了一个 15 人 Steering Committee，来自财务、市场、运营和开发等部门，其中这些业务参与者并不是软件工程师。

他们被要求：

Clone Repository
复制 Agent Template
用 Claude Code 生成配置和Prompt
开 Pull Request
互相 Review

CTO Brandon Fuller 提到，他甚至需要先解释“PR”是什么意思。

一周以后，15 个人都做出了能工作的 Agent。

一个月内，大约 50+ Agent 跑起来。

这说明企业 Agent 普及有一个很有意思的障碍：

难点不一定是让业务人员学 AI，反而可能是让业务人员理解软件工程治理。

他们的 Agent 有一个非常简单的规则：一个名字、一个 Owner、一个工作

我觉得这比“多智能体协同大平台”更值得抄。

每个 Agent：

有名字
有负责人
只做一件明确的事

这个规则能解决很多问题。

如果一个 Agent 叫：

Super Intelligent Business Agent

负责：

分析
审批
客服
财务
营销
代码

出了问题没人知道算谁的。

ABC Legal 的案例更接近：

EvidenceChain Delivery Agent
AR Remittance Agent
Google Ads Analyst
Code Reviewer
Overdue Nudger

职责天然可测。

一个真实例子：EvidenceChain Delivery Agent

以前某客户需要定期拿到特定法律送达记录。

人工流程包括：

查数据库报表
找到匹配任务
打开网站
下载每个PDF
上传客户FTP

现在 Agent 每天自动做。

更有意思的是，案例说设置它的 Account Manager 以前没有做过自动化，大约一个小时，通过描述需求就搭出来了。

这个案例很适合说明 Agent 真正擅长的一类任务：

规则相对稳定
步骤重复
跨多个系统
人工很烦
结果容易验证

不是所有知识工作都适合 Agent。

但这种任务很适合。

另一个例子：eFiling Rejection Diagnoser

法院退回提交后，Agent 自动触发：

读取Job
读取法院规则
判断拒绝原因
把诊断发Slack

原来可能消耗员工数小时的事情，案例说现在大约一分钟给出诊断。

这里我更在意的是“触发式 Agent”。

很多企业仍把 Agent 理解成：

员工主动打开一个Chat

实际上更有价值的形态往往是：

业务事件发生
→Agent自动执行

这就是为什么 Agent 需要 Trigger 和 Schedule 成为配置的一部分。

他们还有一个 98% 的数字，但要看怎么理解

案例提到一个运营 Review Agent，叫 Charvis。

它检查已完成的服务任务，目前与 Compliance Team 的判断大约有 98% 的一致率。

这个数字很适合做 Automation Gate。

也就是：

先推荐
人审核
收集一致/不一致
达到阈值
再逐步自动执行

而不是：

模型看起来挺聪明
直接全自动

“每个 Agent 先有人监督”是他们很重要的一条原则

案例里写得非常清楚：大多数 Agent 一开始先 Human-in-the-Loop。

Agent 给推荐。

人接受或拒绝。

反馈会留在：

业务Banner
或
Slack Thread

等某个 Agent 证明自己在特定任务上和人一样好或者更好，再转到 automation mode。

我认为这比定义一个“Agent自治等级”表格实用得多。

真正需要的是证据：

在这个具体Task上
持续多久
多少样本
一致率多少
严重错误多少

最让我觉得有意思的是 Harvester + Tuner

ABC Legal 并没有一上来做模型微调。

对于有明确人工反馈的 Agent，他们用了三个角色：

Initial Agent
Harvester
Tuner

Initial Agent：

正常做业务

Harvester：

每小时/每天收集Slack反馈
把回复和Emoji转成标签

Tuner：

每周分析反馈
提议修改Prompt或Config
开PR

注意：

Tuner只开PR
不自己改生产

人 Review 后才 Merge。

这个闭环非常值得抄。

反馈不是拿来“训练大模型”的，也可以很有价值

企业里经常一说反馈闭环，就跳到：

Fine-tuning
RL
训练模型

其实 Prompt/Config 层已经可以做大量改进。

例如：

判断条件
Tool顺序
阈值
输出格式
异常处理

这些都可以通过 Git PR 演进。

成本远低于模型训练。

他们甚至把业务规则也放进 Git

案例里提到一个 deliveries-as-code 系统。

大约 145 组 routing rules 不是放在后台管理界面的数据库记录中，而是：

145个YAML文件

在 Git 里。

一个 Agent 每周给判断，Harvester 收反馈，Tuner 修改 YAML 开 PR，第四个 Agent 只把人工已经批准并合并的配置推到生产数据库。

这其实已经不是“Agent as Code”。

更像：

Business Rules as Code

这条路线很有潜力。

因为 LLM 最擅长处理的东西，本来就是文本。

业务规则如果能从：

隐藏在数据库后台

变成：

可读、可Diff、可Review的文本

Agent 才容易参与改进。

成本方面，他们也没有只看 Token

ABC Legal 跟踪每个 Agent 带来的价值和运行成本。

案例里提到一个 efficiency ratio：

Agent创造的价值
/
Agent运行成本

每次运行都会把时间价值和金额回传数据仓库。

这个思路比：

这个月Claude花了5万美元

强得多。

总账单没法告诉你哪个 Agent 值得留。

应该看到：

Agent A
$1000/月
节省$12000人工

Agent B
$800/月
只省$300

B 就应该优化或下线。

他们也做模型分层

案例里的默认思路大致是：

大多数Agent：Sonnet
高频快速任务：Haiku
真正需要深度推理：Opus

不是所有 Agent 都上最贵模型。

这和我们昨天写的模型路由逻辑基本一致：

Task Value
×
Model Cost

而不是榜单排名。

如果让我从这个案例里只抄 7 件事

我会抄：

1. 每个Agent一个Owner
2. 每个Agent一个明确Job
3. Prompt/Tool/Schedule/Memory进Git
4. 所有修改走PR
5. 先HITL，再自动化
6. 反馈变成结构化标签
7. 每个Agent单独算ROI

至于平台用哪家，反而是第二层问题。

还有一件不能忽略：这是供应商案例

这篇材料来自 Anthropic 官方客户案例。

所以像“最高约 50% 的人工任务成本下降”这类数据，应该理解为 ABC Legal/Anthropic 公布的案例数据，而不是独立第三方审计结果。

写企业选型报告时，我会把它标成：

Vendor-reported customer case

但这不影响里面很多工程做法值得参考。

尤其是 Git、PR、Owner、HITL、ROI 这些，本身与供应商无关。

最后

我看完这个案例，最大的感觉是：

Agent 真正进入企业以后，最后还是会回到软件工程。

你不能永远靠：

某个很懂AI的人
在某个页面里
维护一段神奇Prompt

规模上来以后，一定会问：

版本呢？
Owner呢？
谁Review？
怎么回滚？
成本多少？
错误怎么收集？
什么时候能自动？

ABC Legal 的 50+ Agent 最值得抄的，不是数量。

而是他们很早就把这些问题当成：

软件工程问题

来解决。

这可能比再换一个更强的模型，更接近企业 Agent 真正的规模化路径。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/