企业 AI · Agent 治理 · Harness
15个非工程人员，一周做出15个Agent：企业真正该抄的是这套护栏
ABC Legal 把 Agent 的创建权交给业务人员，却没有把上线权一起交出去。这个差别，决定了它是在扩张生产力，还是在批量制造风险。
Anthropic 最近发布了一个企业案例。
美国法律文书送达公司 ABC Legal 有 1100 名员工。公司先组织了一个 15 人小组，成员来自财务、营销、运营和开发等部门，但都不是软件开发者。
他们复制一份模板，用 Claude Code 描述 Agent 要做的事，再补齐配置。一周后，15 个人都做出了可以工作的 Agent。大约一个月后，公司已有 50 多个 Agent 在生产环境运行。
这组数字很容易让人兴奋：以后业务人员是不是都能自己"招"一个数字员工？
我读完案例，反而更在意另一个细节。
ABC Legal 放低了创建 Agent 的门槛，同时把上线后的管理做得更严。业务人员可以提出需求、搭出 Agent，但每一次修改都得留下记录、经过审核，还要能随时退回上一版。
这才是这家公司敢把 Agent 铺开的原因。
大多数企业卡住的，并不是没人会搭 Agent
今天做一个能跑的 Agent，已经不算稀奇。
找个模板，接上工具，写一段指令，半天就能跑出结果。难题通常出现在第二天：
• 这是谁做的，谁在维护？
• 它现在用的是哪一版指令？
• 它能读取哪些资料，又能执行哪些动作？
• 昨天还能用，今天为什么突然变了？
• 出错以后，谁能让它停下来？
• 修改之后，怎么证明它比上一版更好？
个人实验可以靠记忆。公司里一旦出现几十个 Agent，靠记忆就会失控。
有的 Agent 藏在员工电脑上，有的定时运行，有的拿着长期有效的账号权限。负责人离职以后，可能没人知道它还在不在跑。业务规则改了，旧 Agent 仍按旧口径办事，直到某次事故才被发现。
Agent 数量越多，这类问题越不像技术故障，更像一家公司突然招了几十名没有工牌、没有主管、也没有工作记录的临时员工。
ABC Legal 先解决的，就是这件事。
他们给每个 Agent 配了一本"受控操作手册"
ABC Legal 的做法并不神秘。
每个 Agent 都有统一目录和模板。它的任务说明、可用工具、运行时间、凭证和记忆，都被放进配置文件，统一存进 Git。
不熟悉 Git 的读者，可以把它理解成一套带时间机器的公共档案柜。
谁改了哪句话、为什么改、谁同意的，档案柜都会留下记录。新版本出了问题，还能退回上一版。
更关键的是，任何修改都不能直接生效。修改者先提交一份变更申请，也就是开发团队常说的 PR，经过别人检查和批准，才能合并上线。
这套机制至少补上了五块护栏：
一是有主人
每个 Agent 都有名字、负责人和一项明确工作。出了问题，团队不用先猜"这东西是谁搭的"。
二是有边界
工具、凭证和运行方式写在配置里。Agent 可以做什么，不能只存在创建者的脑子里。
三是有版本
业务规则变化时，团队知道改的是哪一版。结果变差，也能找到变化从哪里开始。
四是有审核
业务人员有创建权，但修改进入生产前仍需人工批准。它没有把"人人可参与"误解成"人人可随意上线"。
五是能回退
新配置跑坏了，可以恢复到已验证的旧版本，不必在事故现场重新猜一遍正确答案。
这就是 Harness 在企业里的价值。
它不是又一个漂亮的技术名词。更像赛车周围的方向盘、刹车、仪表盘和维修记录。发动机决定车能跑多快，Harness 决定这辆车能不能在真实道路上长期跑。
Agent 会变好，不等于模型会自己进化
案例里还有一段很值得拆开看。
ABC Legal 的 Agent 在人的监督下工作，并把执行结果或建议发到 Slack。员工可以在线程里回复，也可以用表情反馈。
这些看似随手的动作，没有停留在聊天记录里。
一个名为 Harvester 的角色按小时或按天收集反馈，把回复和表情整理成带标签的数据。另一个 Tuner 每周查看这些数据，提出指令或配置的修改建议，并自动发起 PR。
到这里，它仍然没有权力直接改生产环境。最后一步由人审核和合并。
整条链路可以压缩成六步：
1. Agent 完成真实任务并留下记录； 2. 员工对结果作出反馈； 3. 系统把反馈整理成可分析的数据； 4. Tuner 提出指令或配置修改； 5. 人检查变更和风险； 6. 新版本上线，继续观察。
模型没有重新训练，Agent 仍然可以改善。
因为生产中的很多错误，并不是模型"不够聪明"。有时是指令没写清，有时是工具给错了，有时是资料过期，还有时是运行时间或权限不合适。
看到错误就换模型，像员工把表填错一次，公司就给他换一颗大脑。多数时候，先把岗位说明、资料、权限和复核方式改清楚，成本更低，也更容易验证。
这套案例最值得企业抄的，是六个动作
如果一家企业也想让业务人员参与构建 Agent，不必一上来复制 50 个。先把下面六件事做出来。
1. 只从一项清楚的工作开始
第一批 Agent 最好只有一个任务，输入和输出能说清，出错后有人接管。
不要从"做一个公司万能助手"开始。可以从核对一类资料、生成一份固定报告、诊断一种常见异常开始。
2. 给所有 Agent 一张统一登记表
至少写明名称、负责人、服务对象、任务范围、资料来源、可用工具、运行频率、人工接管方式和停用条件。
先登记，再上线。否则三个月后，企业连自己有多少 Agent 都数不清。
3. 把配置集中管理
提示词不要散落在聊天记录和员工电脑里。工具清单、资料版本、运行计划也要一起管理。
企业不一定非要照搬 Git，但必须具备版本记录、审核和回退能力。
4. 给上线加一道人工闸门
创建者不能独自决定生产上线。涉及客户沟通、内部数据、财务、法务或外部执行的 Agent，更要明确谁审批、谁承担结果。
5. 从第一天就收集反馈
不用先建复杂平台。一个"有用/没用"、一个错误原因选项，再加一段补充说明，就能开始积累真实案例。
关键是把反馈和当时的输入、输出、工具调用、配置版本放在一起。孤零零的一句"答错了"，很难指导改进。
6. 用固定测试题守住发布
每次修改之前，先拿一组代表性任务测试。旧问题有没有修好，新版本有没有把原来正确的地方改坏，都要有记录。
PR 只是一个审批动作。没有测试证据，审核人看到的仍然只是一段看起来更顺的文字。
三个数字，也要冷静看
Anthropic 的案例还披露，截至 2026 年 7 月，ABC Legal 有约 310 名员工日常使用 Claude；部分 Agent 覆盖的人工任务，成本最高下降约 50%，而且是在"尚未重度优化"之前。
这些结果很亮眼，但它们来自供应商发布的客户案例，不能直接外推到其他企业。
还有三个容易混淆的地方：
• 50 多个 Agent，不等于 50 个成熟产品。 很多可能只处理一项窄任务。
• 非工程人员会创建，不等于可以绕过工程治理。 恰恰相反，他们能参与，是因为模板、审核和运行环境先被搭好了。
• Agent 数量不是最终成绩。 企业仍要看处理时间、错误率、人工接管、成本和业务结果。
如果一家公司的 Agent 从 5 个涨到 50 个，员工却要花更多时间盯着它们，这不叫规模化，只是把新的维护工作扩了十倍。
门槛越低，护栏越要提前
ABC Legal 的案例值得看，不在于 15 个人一周做出了 15 个 Agent。
现在让一个业务人员描述需求、生成配置，已经越来越容易。更难的是，当第 16 个、第 30 个、第 50 个 Agent 出现时，公司还能回答这些问题：
它归谁负责？拿了什么权限？依据哪版规则？出了什么错？谁批准了修改？能不能马上停下并退回？
这些问题答得出来，业务人员创建 Agent 才是生产力民主化。
答不出来，所谓"人人都是 Builder"，很可能只是把影子 IT 换成了影子 Agent。
企业降低 Agent 的创建门槛时，也该同步提高进入生产环境的门槛。
这两扇门，必须一起设计。
资料来源： Anthropic 于 2026 年 8 月 17 日发布的客户案例 How ABC Legal turned every employee into a builder with Claude Managed Agents。文中人数、时间、Agent 数量和反馈机制来自该案例；成本与使用数据为厂商披露口径，本文已保留限定。
完