---
title: "给 Agent 立法"
author: Miles Ma
date: 2026-06-14
section: Agent 系统
url: https://immilesma.com/blog/harness-engineering-ai-first/
description: "Agent 真正进入企业流程之前，需要明确上下文、权限、验收标准和失败边界。Harness 就是把这些规则装进运行环境。"
---

# 给 Agent 立法

> Agent 真正进入企业流程之前，需要明确上下文、权限、验收标准和失败边界。Harness 就是把这些规则装进运行环境。

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

为什么有些 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 系统。**