给 Agent 立法

最近我一直在想一个问题。

为什么有些 Agent 看起来配置已经很完整了，MCP 接了，知识库也有，Skills 也写了，甚至 Claude Code、Codex 这类工具也都用上了，可一旦放进真实流程里，还是会让人不太放心？

这个“不放心”不是空穴来风。

MCP 确实能让模型去取数、查库、调系统。知识库也确实能让模型拿到组织内部资料。Skills 可以把一些固定流程封装起来。上下文工程解决的是，模型在这一轮任务里到底该看见什么。

这些东西都很有用，但它们解决的是局部能力。真正难的地方，是让 AI 进入一条真实工作流以后，产出能被组织信任。

你可以给 AI 一堆工具，它还是可能把事情做歪。你可以给它一个知识库，它还是可能从一堆资料里挑错重点。你可以给它一个标签体系，它嘴上答应得很好，跑起来却自己造一张关键词表，然后用关键词匹配给你糊出一份看起来很整齐的统计。

这个例子我很在意。

比如你要做自动标注。你有一套标签体系，要让 Agent 按这套体系去给内容打标。一个常见的做法是，把标签体系扔给 Claude Code 或 Codex，让它帮你处理一批数据。

它很可能会怎么做？

它先读一遍标签说明，然后自己总结出一套关键词。看到“融资”“投资人”“估值”，就打创业融资。看到“出海”“北美”“东南亚”，就打全球化。看到“模型”“prompt”“agent”，就打 AI。

最后它给你一张表，每条内容都有标签，统计也很好看。你甚至会觉得它完成得很快。

但这套数据很可能是脏的。

因为它完成的是“看起来像标注”的任务。真正的标注应该是逐条判断。每一条都要回到标签定义里，判断它到底属于哪个标签，为什么属于这个标签，是否存在冲突，是否无法判断，置信度是多少。更进一步，它的输出应该被 JSON Schema 固定下来，方便你做校验、入库、抽样复核和后续统计。

这里就出现了一个很关键的区别。

**JSON Schema 很有用，但它不是整套 Harness。它更像 Harness 里最小的一条机器可执行法律。**它规定结果长什么样，却没有规定判断怎么来，也没有规定错了怎么查、冲突怎么处理、哪些样本必须复核、复核结果怎么回流。

很多 Agent 系统的问题就在这里。大家给了 AI 工具，却没有给它法。

Harness 这个词，真正有用的地方#

最近硅谷开始频繁讨论 Harness Engineering。这个词直译成“挽具工程”，听起来有点别扭。有人把它比作 Agent 的操作系统，也有人说 Agent = Model + Harness。

这些比喻都能帮助理解，但我觉得还不够。

如果只把 Harness 理解成一套工具链，很容易把它讲窄。工具、MCP、Skills、沙箱、权限、记忆、评估器、日志、trace、上下文压缩，这些当然都是 Harness 的组成部分。可它们拼在一起，最后要处理的是一个更现实的问题：AI 干出来的东西，组织敢不敢拿来用。

这才是 Harness 的位置。

MCP 解决的是 AI 能调用什么。

知识库解决的是 AI 能读到什么。

Skills 解决的是 AI 遇到某类任务时按什么套路走。

Schema 解决的是 AI 输出必须长成什么样。

Harness 要解决的是，AI 进入一条真实工作流以后，它的输入、工具、状态、权限、验证、反馈、记忆和修正机制如何被组织起来。

放在刚才的标注例子里，Harness 不是一句“请严格按标签体系打标”。它应该包括：

标签体系的定义文件。每个标签有解释，有边界，有正例和反例。

每条内容单独进入判断流程，不能先被压缩成一张关键词表。

输出必须符合 JSON Schema。标签、理由、置信度、冲突项、无法判断原因，都要有固定字段。

系统要有抽样复核。复核发现错标后，不能只改这一条，还要回头看是标签定义不清，还是提示词不够，还是模型偷懒走了捷径。

统计结果要能追溯到单条判断。不能只给一张汇总表，让人不知道数字从哪里来。

这才像一个能进入业务的标注系统。

所以我更愿意这样定义 Harness：

Harness 是围绕 Agent 搭出来的一套执行环境。它把组织对“什么算对”的判断，变成模型能读取、能执行、能被检查、能持续修正的流程。

这个定义会把 Harness 和 AI-First 组织接起来。

自动化日报不是取数，知识库也不是检索#

再看一个更日常的例子：自动化日报。

很多人会说，这有什么复杂的？用 MCP 连数据库，把昨天的数据取出来，再让 AI 总结一下，不就行了。

真上过线就知道，不是这么回事。

取数只是这件事里最简单的一步。真正麻烦的是日报背后的判断标准。

哪些指标每天必须看？
哪些指标只在异常时看？
什么幅度算异常？
数据缺失时能不能发？
同比、环比、移动平均，哪个口径优先？
AI 写的结论必须引用哪几个数据点？
遇到无法解释的波动，是安静略过，还是提醒负责人？
日报发出去以后，第二天有没有人对它的判断做校准？

这些问题没有被写下来，AI 每天都会自己补。它会用训练数据里的“日报感”来填空。写出来的东西可能很顺，但它不一定是你这个组织能用的日报。

知识库问答也一样。

很多团队以为，把文档丢进向量库，然后接一个聊天框，就是 AI 知识库。可一个真正能用的知识库系统，难点远远超出检索。

它要知道哪些知识可信，哪些已经过期。它要处理同一问题在销售、客服、法务、产品文档里的口径冲突。它要知道什么时候必须引用原文，什么时候可以总结，什么时候应该拒答。用户反馈回来以后，系统还要知道这次是检索错了、排序错了、答案写错了，还是知识库本身该更新。

没有这些，知识库只是给 AI 多塞了一点资料。塞得多了，还会制造新的问题。资料越多，AI 越容易在里面挑一段看起来顺手的，拿来支持一个它已经想好的答案。

所以自动化日报不能只盯着 MCP，知识库问答也不能只盯着 RAG。它们都需要一层更上面的东西：把组织的判断标准写进系统。

这个东西，在 Agent 工程里叫 Harness。在组织语境里，我更愿意叫它法。

AI-First 组织，先要写出自己的法#

大神的架构师教程里讲过几个很重的判断。

**AI 时代的架构师，价值不在写最多代码，而在把混沌变成可执行、可验证的系统。**未来组织不能只靠任务分配，更像是把人和机器组织成一支公会。再往上，是立法者思维，也就是定义什么算对、什么算好、什么时候该承认失败。

这几个判断刚好补上了 Harness 讨论里经常缺掉的那一层。

很多 Harness 文章会讲工具链、沙箱、上下文、评估器、权限、trace。这些都对。但如果再往上问一句：这些机制到底在执行什么？

答案就是法。

日报系统执行的是你对业务健康度的法。

知识库系统执行的是你对组织口径的法。

标注系统执行的是你对分类和统计的法。

代码 Agent 执行的是你对架构、质量、安全和发布流程的法。

一家 AI-First 团队最值得咀嚼的地方，其实不在“99% 的代码由 AI 完成”。这个数字当然抓眼球，但它只是结果。真正值得看的是，他们把产品开发流程里的大量隐性判断搬进了系统。

功能做完之后，系统会看顶层指标有没有变化，看真实用户有没有使用，看日志里有没有 error，看测试有没有过，看 incident 有没有出现。上线和回退，不再完全依赖会上的口头判断。

bug 出现以后，Agent-driven 的 bug triage 会先识别、分类、指派。风险小的文件夹，auto-fixing 系统甚至可以自动开 PR，由工程师做最后批准。

产品、工程、市场之间的对齐，也开始被 AI 接管一部分。过去市场团队追着工程问明天发什么功能，现在工程速度反过来超前市场，AI 可以把工程进展、上线计划、数据反馈同步给其他团队。

这不是简单的“AI 写代码更快”。这是组织的运行方式变了。

以前组织靠人脑和会议维持秩序。产品经理在中间对齐需求，工程经理排期，测试守质量，架构师守边界，市场追进度。每个角色都在用自己的经验和判断，临时填补系统没有写清楚的部分。

AI-First 之后，这些判断不能继续只存在于人脑里。

因为 AI 不会自动知道你们公司“什么算一个好功能”。它也不会自动知道什么样的 bug 可以自己修，什么样的改动必须升级给人。它更不会自动理解你们团队过去几年靠默契形成的那些边界。

你不写，它就借别人的法。借模型训练数据里的法，借开源项目里的法，借它见过的通用 SaaS 流程里的法。

这就是很多 AI 系统“看起来很聪明，用起来不对劲”的原因。它不是不会做事，它是在按别人的世界观做事。

Harness 是把法装进机器里的方法#

把这个问题想清楚以后，Harness 的每个组件都会变得更容易理解。

上下文管理，远远超出给 AI 塞内容。它是在告诉 AI，哪些法条永远要看见，哪些案例需要时再查，哪些历史记录只能通过搜索触达。

**AGENTS.md、CLAUDE.md、项目规范、标签定义、日报口径、客服话术，这些都不是普通文档。它们是系统的法条。**写得太散，AI 找不到。写得太长，AI 看不住。写得太虚，AI 执行不了。

工具和 MCP，也不是越多越好。工具是执法能力。一个系统到底给 Agent 开哪些工具，等于告诉它可以动哪些现实对象。能读数据库，能改代码，能发消息，能删文件，能开 PR，能付款，这些权限的风险完全不同。

所以工具必须和权限、审批、审计放在一起设计。否则就是给一个很会猜的人发了一串钥匙。

JSON Schema、结构化输出、固定字段，属于格式法。它们把 AI 的结果变成机器能检查的数据。没有这层，AI 每次输出都像一段散文，人读着顺，系统接不住。

评估器是法官。它不能只问生成者“你做完了吗”。它要自己跑测试，自己打开浏览器，自己查日志，自己对照标准打分。这里也有一个很有意思的问题：Agent 有时会找到比标准答案更好的解法，结果被评估器判失败。这说明评估器本身也要被评估。法官也会错。

日志、trace、事件流，是审计。没有审计，AI 做了什么就会变成一团雾。尤其当 Agent 开始跑长任务、调工具、调用别的 Agent 时，光看最后答案完全不够。你要能回放它每一步为什么这么做，调用了什么，拿到了什么结果，在哪里分叉，在哪里失败。

记忆和反馈，是修法机制。

一个系统跑久了，环境会变。文档会过期，业务口径会变化，工具会升级，用户会用出新问题。好的 Harness 不是把一堆规则一次写死。它要能从失败里提取信号，把信号变成可验证的经验，再把经验沉淀成新的规则。

这也是 self-healing、self-improvement 最有价值的地方。Agent 遇到困难，不能只让人去修那一次任务，更要反过来看系统缺了什么。缺的是上下文，补文档。缺的是约束，补 linter。缺的是验证，补测试。缺的是权限边界，补审批。

这时，人做的事情已经变了。

人不再是每一步执行的监工。人更像写法、修法、处理例外的人。

每人一个 AI 助手，还不够#

很多公司说自己 AI-First，其实只是每个岗位都开始用 AI。

工程师用 AI 写代码。产品经理用 AI 写 PRD。设计师用 AI 出图。市场用 AI 写文案。

这当然有价值，但它仍然是旧组织。人还是流程的主语，AI 只是每个人手里的加速器。速度会变快，混乱也会变快。

有团队踩过一个很反直觉的坑：一开始每个人都用 AI，结果并没有真正提高组织效率，反而带来了更高的对齐成本。每个人都被 AI 加速以后，节奏不一样，产物不一样，理解不一样，最后组织要花更多时间互相解释。

这很真实。

个人提效到一定程度，会撞上组织摩擦。一个人写得快，另一个人审不过来。工程做得快，市场消化不了。功能上线快，反馈系统跟不上。所有人都在加速，组织反而更像一辆每个轮子都独立转速的车。

AI-First 的分水岭，不是“人人都有 AI”。真正要看的，是组织有没有一部分流程可以交给 AI 主导运行。

这句话听起来很激进，但落地以后其实很具体。

比如开发流程。需求进入以后，AI 先拆方案。人看的是计划有没有方向性问题。代码生成以后，测试、linter、Playwright、日志检查、LLM review 形成一套回路。上线以后，指标和 incident 继续回流。每一步都有边界，有证据，有可回放的记录。

比如市场流程。AI 可以生成内容、投放变体、跟踪数据、总结反馈。但什么样的内容能代表品牌，什么样的数据算有效，什么情况必须停，什么情况值得加码，这些不能交给模型现场发挥。它们要被写成系统能执行的判断标准。

比如知识库流程。新文档进入以后，AI 可以做拆分、摘要、索引、冲突检测。用户问答以后，AI 可以记录命中情况和失败样本。但哪些知识可以对外说，哪些只能内部看，哪些说法需要法务确认，哪些答案必须拒绝，这些都要成为系统的一部分。

AI-First 组织的样子，大概不是一群人坐在电脑前各自召唤 AI。更像是一套永不暂停的系统在跑，人定期登录进去，查看世界状态，处理最承重的判断。

这点和大神架构师教程里那个 MMO 比喻很接近。未来的人机协作不会只按同步上班、同步开会、同步下班来设计。Agent 不睡觉，它们会在你离线时继续跑任务。你早上回来，第一件事是读懂系统在夜里变成了什么样，然后下一个判断。

这对人的要求更高了。

你不能靠实时盯梢管理一支机器队伍。你要靠循环、反馈、权限、日志、验收标准管理它。

换句话说，你要靠 Harness。

新架构师：定义系统，别追着补每个洞#

AI 写代码的能力已经很强。真正值钱的，是发现 AI planning 的缺陷。哪里有安全问题，哪里有延迟问题，哪里架构边界不对，哪里看起来能跑但未来会塌。

这和大神架构师教程里的说法可以接上。AI 是软件工程这座抽象塔上很高的一层。它把很多实现细节包起来，让你用自然语言描述需求，然后产出代码、文档、流程甚至完整系统。

抽象越高，泄漏时越危险。

低层抽象泄漏，可能是性能问题。AI 这层抽象泄漏，可能是逻辑错了、边界错了、判断标准错了，而且它会用很漂亮的方式把错东西交给你。

所以新架构师的价值，不是他能不能比 AI 写得更快。大概率写不过。价值在于他知道什么时候不能信表面，知道往下掉一层看什么。

他要能把模糊需求拆成对象，给每个对象画边界、定契约。
他要站在代码上一层，写出能生成代码和流程的规格。
他要在 AI 开始执行前，先定义什么叫对。
他要知道哪些地方可以放手，哪些地方必须上电网。

这里的电网就是测试、评估器、linter、schema、权限、日志、trace。

**这些东西听起来很工程，但本质上是在保护人的判断力。**系统越大，人越不可能亲自看每一步。一个人想指挥几十个 Agent、几百个任务、几千条数据流，靠勤奋没有用。你不能把所有状态塞进脑子里。

架构师的工作，是把“记住”和“盯着”外包给系统。

日报有没有引用真实数据，让系统查。
标注有没有符合 schema，让系统验。
代码有没有越过架构边界，让 linter 拦。
Agent 有没有调用高风险工具，让 approval gate 停。
知识库答案有没有引用过期文档，让审计链暴露出来。

人省下来的注意力，要用在更少、更重的地方。

这也是为什么我觉得“AI organization”这个词不能只从组织架构图去理解。真正的 AI organization，不是把原来的人类岗位旁边都放一个 AI，也不是把组织图改成“人类员工 + AI 员工”。

它是把组织里那些长期靠人脑、默契、经验、会议维持的判断标准，逐步外化成可执行系统。

这个过程里，架构师不像传统意义上的技术负责人，也不像传统意义上的管理者。他更接近立法者。

他写下系统为什么存在，什么算好，什么算坏，什么情况必须停，什么能力可以长出来，什么权限永远不能给，什么反馈可以改法。

然后让人和机器在这套法下面工作。

法不能太多，Harness 也不能太厚#

讲到这里，很容易滑向另一个误区：什么都要立法，什么都要上 Harness。

这也会出问题。

有些任务就是一次性的。临时写一段文案，翻译一封邮件，整理一份低风险资料，直接用聊天框就可以。给它上权限系统、审批流、审计链、评估器，成本比收益高。

有些任务处在探索期。你还不知道什么算好，也不知道哪条路走得通。这时候太早把流程刻死，会把系统变成一座小监狱。模型本来可以试出一些你没想到的路径，你先把它绑住了。

工具也不是越多越好。有个 text-to-SQL Agent 的案例很典型，早期给了很多专用工具，成功率反而不够好。后来删掉大部分工具，只保留 grep、cat、find、ls 这类基础能力，让模型自己读 schema 文件，效果更好。

这个例子很重要。

Harness 的目标不是把 Agent 管到动不了。它的目标是让 Agent 在该自由的地方自由，在该收紧的地方收紧。

怎么判断厚度？

我会看四个问题。

第一，这个任务是否高频。如果每天跑、每周跑、持续跑，值得做 Harness。一次性任务通常不值得。

第二，错误有没有代价。写错一句草稿和发错一封客户邮件，不是一回事。改坏本地代码和误操作生产数据库，也不是一回事。

第三，结果能不能验证。能写测试、能查数据、能抽样复核、能对照现实反馈的任务，更适合交给系统跑。完全主观、标准还没形成的任务，先别急着自动化。

第四，组织会不会依赖它。如果 AI 产出会进入报表、决策、客户回复、代码主干、财务流程，那就不能只靠模型自觉。

厚 Harness 应该用在高频、高风险、可验证、组织依赖的地方。

轻任务就轻做。探索任务先让它跑起来。等失败样本出现，等判断标准开始稳定，再一点点把规则沉淀进去。

好的法也不是一开始写满。根要少，边界要清楚，剩下的在现实里长。

组织的判断标准，要从脑子里抠出来#

说到底，AI-First 组织最难的第一步，可能和 AI 没什么关系。

它要求你把组织里那些含糊的判断标准写出来。

什么叫一个好客户？
什么叫一条高质量线索？
什么叫一篇可以代表品牌的文章？
什么叫一次有效的产品实验？
什么叫一个必须立刻修的 bug？
什么叫一个可以容忍的边界情况？
什么叫一个系统已经失败，应该关掉？

这些问题过去也存在，只是可以被人糊过去。老板拍板，产品经理协调，资深员工凭经验判断，团队靠默契消化。

AI 进来以后，糊不过去了。

因为 Agent 要执行，就必须有输入。要判断，就必须有标准。要改进，就必须有反馈。你不写清楚，它就自己补。补得顺手的时候，你会误以为系统很聪明。补错的时候，你才发现短板并不在模型能力上，而在组织自己的法没有成文。

大神的架构师教程里有一句意思很重：墙上的价值观管不住任何东西，判断一个组织有没有法，要看它最近一次艰难决策引用的是墙上那句话，还是老板当时的心情。

把这句话放到 AI-First 组织里，也一样。

判断一个组织有没有 Harness，不看它接了多少 MCP，不看它买了多少 Agent 工具，不看它的知识库有多大。要看最近一次 AI 做错事之后，组织有没有能力追溯原因、修正规则、更新流程，让下一次少犯同类错误。

如果没有，那些工具只是外挂。

外挂会放大你已有的东西。你的判断标准清楚，它放大的是系统能力。你的判断标准混乱，它放大的就是混乱。

最后#

Harness 这个词会继续火。它会被包装成框架、平台、模板、开源项目，也会变成一堆新的缩写。

这些都可以学，但别被词带跑。

真正的问题更朴素：你要让 AI 替你跑哪一段流程？这段流程里，什么算对？什么算错？谁有权决定？错了怎么发现？发现后怎么改？哪些东西可以自动做，哪些东西必须让人看一眼？哪些经验要留下来，哪些能力应该退役？

能回答这些问题，MCP、Skills、Schema、评估器、沙箱、trace 才有地方落。

答不出来，工具越多，系统越像一台装满按钮的机器。看起来很先进，真出事时没人知道哪个按钮该按，哪个按钮当初就不该装。

所以我现在更愿意把 Harness 看成 AI-First 组织的法律系统。

它不是终点。它只是一个工程名字，用来描述一件更老也更难的事：把人的判断写出来，让机器照着执行，让现实不断校准它。

AI 让执行变便宜以后，组织里真正贵的东西变成了定义。

谁定义什么算对，谁就拥有这套 AI 系统。