秩序, 不是工具: 为什么 Agent Harness 的定义是一个类别错误
2026 年有一个共识: Agent = Model + Harness。
Harness 是 model 以外的一切。工具、记忆、上下文管理、权限、可观测性。打开任何一个 agent framework 的文档, 看看 harness 章节在讲什么。都是这些。
这不是一个错误。这是一个类别错误。
它回答了 HOW — 怎么让 agent 执行得更好。但它没回答 WHY — agent 为什么存在。也没回答 WHAT — 什么该做, 什么不该做。
一个有 19 个工具、5 种记忆策略、完美上下文管理的 agent, 如果没有目标和边界, 只是一个非常高效地原地打转的机器。
秩序
每个系统都趋向混乱。
不是因为系统设计得差。是因为混乱不需要努力, 秩序才需要。一个没有规则的 agent 会做什么? 什么都做。什么都做就是什么都没做。
问题不是 “怎么让 agent 做得更好”。问题是: 什么是 “好”?
如果你没有先定义什么是秩序, 那每个版本看起来都可能是混乱的。回滚到哪里? 优化什么方向? 不知道。你只能回到最初。
所以在讨论工具、记忆、上下文之前, 先回答一个更基本的问题: 什么状态是有序的, 什么状态是混乱的。
框架
为什么要有公司?
实现目标。
为什么要有多个 agent?
因为多个 agent 可以更好地实现目标。
为什么要有 harness?
因为没有边界, agent 就乱干。没有边界就没有规则, 没有规则就原地打转。
这不是类比。公司是 agent 组织的原型。Agent 组织面临的是完全相同的问题。
Goal. 公司存在是为了实现目标。Agent 存在也是为了实现目标。没有目标的 agent 是噪音。目标不是 “回答用户的问题” — 这太模糊了。目标是具体的、可衡量的。
Scope. 员工有 job description — 这就是 scope。员工有 KPI — 这就是 objective function。最佳实践不是静态规则, 是前瞻性框架: 结合实际情况, 预测未来发展方向, 而不是只看明天的短期利益。边界应该越来越清晰, 维护变更的成本也是衡量因素。
Governance. 接近目标, 继续。远离目标, 回滚。晋升、降职、重组 — 都是治理。不是官僚模型, 是进化模型。跟梯度下降一样: 沿着减少 loss 的方向走。
Harness 不是工具的集合。Harness 是递归的 Goal + Scope + Governance。
秩序定义
设计模式、架构、面向对象的本质不是 “怎么写代码”。是定义什么是秩序。
Interface 定义组件间的契约。SOLID 定义变更的秩序。测试定义 “正确” 的边界。这些不是编程技巧。这些是秩序定义。
Best practice 不是起步模板。Best practice 是秩序的定义。它告诉你 “好的状态” 长什么样, 什么行为是有序的, 什么是混乱的。没有 best practice, 就没有秩序定义。没有秩序定义, 就无法区分好坏。
一旦进入无序的混乱, 似乎就只能推倒重来, 或者回滚到之前版本。但如果没有定义好什么是秩序, 那么每一个版本都是混乱版本。我们只能回到最初。
治理有三层, 每层是上层的前提:
Layer 0: 秩序定义。 什么是 “好的状态”? 不先回答这个问题, 优化和适应都无从谈起。
Layer 1: 优化。 在秩序定义下, 今天比昨天好吗? 接近目标, 继续。远离目标, 回滚。
Layer 2: 适应性。 不只是 “今天比昨天好”。是: 如果明天出现了今天没有的情况, 系统还能不能迅速调整? 坏代码今天能跑, 需求一变就碎。好架构今天能跑, 明天变了也能快速适应。
好的 harness 同时满足三层。只做 Layer 1 是局部最优, 碰到环境变化就完蛋。只做 Layer 1 + 2 但没有 Layer 0, 你不知道自己在优化什么。
递归
多个 agent 组成一个部门。但对另一个部门来说, 这些 agent 就是一个 agent。
一个部门有自己的 Goal, 自己的 Scope, 自己的 Governance。对外, 它是一个实体。对内, 它是多个 agent 各自有自己的 harness。
Individual Agent: Harness(Goal, Scope, Governance)
↓ compose
Department: Harness(DeptGoal, CombinedScope, DeptGovernance)
对外 = 一个 agent
↓ compose
Organization: Harness(OrgGoal, CombinedScope, OrgGovernance)
对外 = 一个 agent不需要额外的 “协作” 机制。
如果协作需要作为独立概念来设计, 而不是从递归组合中涌现, 说明抽象层次错了。通信是实现细节 — agent 之间怎么传消息。协作是递归组合的副产品 — 多个 agent 组成的整体自然地作为一个 agent 运作。
公司已经证明了这一点。你不需要给 “部门间协作” 设计一个独立的机制。你需要的是: 每个部门有清晰的 Goal、Scope、Governance, 然后公司层面再有一层 Goal、Scope、Governance。协作从结构中涌现。
递归的尽头
秩序定义本身会过时。
当环境变了, 旧的 “什么是好的组织” 不再适用。从流水线到网络, 从命令链到自组织, 从瀑布到敏捷 — 不是旧秩序被打破了, 是旧的秩序定义不再匹配现实。
那就需要新的秩序定义。寻找新的 “什么是好的”。这是 Layer 3。
但新的秩序定义也会过时。那就需要寻找秩序定义的秩序定义。Layer 4。
这个递归有终点吗?
人类自始至终在做一件事: 寻找规律。然后寻找规律的规律。一切规律都可以用数学逻辑表达。数学是秩序定义的最终形式 — 不是因为数学是万能的, 而是因为数学是唯一一种能精确表达 “什么是秩序” 的语言。
组织变更和代码重构是同一个递归的不同实例。公司调整架构是为了更好地服务目标。agent 调整 workflow 也是。这不是 “开发” 的比喻 — 这就是开发。一种基于事件模型的组织开发。核心目标就是让组织更好地服务于目标。
有人正在用机器证明的方式探索这个递归的底层。不是为了找到最终答案。推石头的人不可悲, 因为寻找规律这个过程本身产生秩序。
市场在给 agent 更好的工具。
我们在问一个不同的问题: 什么是秩序。
这是两种完全不同的工程。