单轮模型能力已经足够强，真正困难的问题越来越不是“模型会不会做这件事”，而是它能不能跨越多个步骤、多个小时甚至更长时间，在一个持续变化的环境里稳定工作。

但在讨论 Agent 怎样持续工作之前，还有一个更前置的问题：它究竟被允许在什么业务边界内行动，以及哪些原本隐藏在固定流程里的约束需要被重新显式表达。《Agent 不会消灭工作流，它只会逼我们重新理解工作流》讨论的是这一层；本文继续向下看，当业务环境和行动边界存在以后，Harness 如何连接 Agent 与这个环境。

真实任务不会在一次推理结束时自动结束。Agent 需要记住已经做过什么，知道当前任务推进到了哪里，调用工具、处理失败、恢复上下文，并在新的信息出现以后继续判断和行动。Context、memory、tool use、loop、retry、handoff、skill 等机制，本质上都在解决这个问题。

模型负责一次认知跃迁，Harness 负责让无数次认知跃迁连接成一个持续运行的系统。

这也是今天 Harness 最核心的价值。但如果继续往真实业务环境里走，会发现目前大多数 Harness 解决的仍然主要是问题的一半：Agent 自己这一侧。

01｜今天的 Harness，主要在维护 Agent 自己

一个 Agent 想要长期工作，首先必须保持自身的连续性。它需要知道当前目标是什么，已经执行过哪些动作，哪些信息值得长期保留，形成过什么判断，掌握了哪些技能，下一步准备做什么，失败以后应该从哪里恢复。

这和一个人维护自己的工作系统其实很像。人会写笔记、整理知识库、维护 TODO、记录项目进度、形成自己的工作习惯；Agent 现在使用的 memory、handoff、skill、context compression 等机制，本质上也在承担类似作用。它们帮助一个主体跨越时间，维持自己的任务状态和认知状态。

从这个角度看，今天很多 Harness 可以理解为一种 Actor-side infrastructure：它首先关心的是“这个 Agent 如何持续成为同一个 Agent”。

这是完全合理的起点。早期 Agent 的工作边界比较小，一个 Agent 面对有限任务，环境信息也相对简单，把大量上下文暂时放在自己的 memory 或工作目录里，并不会立刻产生严重问题。

但当 Agent 开始进入长期、多人、多系统、持续变化的真实环境时，一个边界问题会逐渐显现出来：Agent 自己知道什么，和这个世界本身是什么样，并不是同一件事。

02｜主体的认知状态，不等于环境的运行状态

今天很多 Agent 实现里，这两类东西经常被混在一起。

README、memory.md、handoff.md、RAG 检索结果和长上下文，一方面记录 Agent 自己做过什么、学到了什么，另一方面又承担描述外部环境的责任。于是“Agent 记住的世界”逐渐变成了“世界本身”的代理。

在简单任务里，这种方式足够好用。但进入真实业务以后，问题会越来越明显。

例如，一个采购 Agent 可以记住：“上次处理供应商延期时，我先检查了库存，再检查替代料和交期。”这是它自己的经验，可以属于它的 skill 或 memory。

但“供应商 A 当前承诺交期是 10 月 8 日”“项目 X 现在缺 3 类关键物料”“采购任务 Y 已经完成了一半”，这些并不是 Agent 的个人记忆，而是环境事实。

同样，“我判断这个项目可能延期”属于某个 Actor 当前的判断；而“项目有哪些任务、依赖关系是什么、哪些状态刚刚发生了变化”，属于环境本身的表征。

这两类信息在生命周期、责任边界和共享范围上都不同。主体的判断可以被推翻，个人经验可以只属于某个 Agent；但一个订单当前是什么状态，不应该因为换了一个 Agent 就重新定义一次。

主体需要维护自己的认知状态，环境需要维护自己的运行状态。两者不能长期依赖同一份 Markdown 混在一起。

这和人的协作其实没有本质区别。我的个人笔记属于我自己，但团队项目状态不能只存在于我的笔记里；团队可以共享项目空间，但公司的客户、订单、库存、职责和规则也不会因此全部塞进某一个项目文档。

个人知识系统、团队协作空间、企业系统和更大的公共基础设施，本来就属于不同的 scope。

对 Agent 也是如此。

03｜共享上下文，不等于共享理解

如果把主体和环境分开，很多现在看起来像“Agent 能力不足”的问题，会显露出另一面。

Agent 当然需要 perception、reasoning 和 action，但这些能力能发挥到什么程度，取决于外部环境是否向它提供了足够稳定的表征。

如果订单状态从未被持续维护，再强的 Agent 也只能猜当前进度；如果同一个客户在三个系统里拥有不同身份，它就必须反复判断这些记录是不是同一个对象；如果规则只散落在制度文档和聊天记录中，每一次判断都要重新从文字里恢复约束关系；如果一项业务变化发生后，相关任务、指标和依赖没有同步更新，Agent 就会基于一个已经过期的世界继续行动。

但即使信息已经被“共享”出来，问题也还没有结束。

人类协作里早就存在一个非常典型的例子：PRD 为什么需要评审？

PRD 本身已经是一份共享文档。产品、研发、设计、测试看到的理论上是同一套文字，但这并不意味着大家形成了同一套理解。同一句“支持批量修改”，产品可能理解为一个业务动作，研发会进一步追问批量范围、事务边界和失败处理，测试则会关心异常状态、权限和回滚条件。所有人都读过同一份文档，脑子里却可能已经形成了几套不同的系统。

所以才需要评审。

评审真正做的，不只是让更多人“看见 PRD”，而是在发现理解分歧、补充隐含前提、明确边界，并把最终达成的共识重新固定下来。

而且最可靠的做法通常不是“大家聊过就算了”，而是把关键结论继续写回需求、接口、规则或验收条件里。因为如果共识只存在于某次会议里，过几天以后又会重新漂移。

这说明一个更基础的问题：

信息共享，不等于语义对齐；共享同一份文本，也不等于共享同一个世界模型。

多 Agent 协作同样如此，而且问题只会更加明显。

今天常见的做法，是通过共享目录、共享 Markdown、共享 conversation history 或 shared state，让多个 Agent “拥有同一份上下文”。但真实协作中的共享从来不是简单复制同一份信息。

同一个业务对象，本来就可能存在不同主体的视角。销售、采购、生产看到的是同一个项目，但各自关注的属性、状态和关系不同；两个 Agent 也可能基于同一组事实形成不同判断。这里既有共同事实，也有主体私有的信息，还有暂时无法消除的分歧。

如果全部压进一份共享文本，就很难回答：哪部分是共同事实，哪部分只是某个 Actor 的判断？两个判断冲突时应该覆盖、并存还是保留版本？一句自然语言究竟对应哪个对象、哪个状态、哪条规则？多个主体是否真的在讨论同一件事？

权限问题也会进一步放大复杂度。不同 Actor 本来就应该拥有不同的可见范围和操作权限。一个采购 Agent 可以看到供应商报价，但生产 Agent 未必需要；管理者能够看到跨部门经营指标，也不意味着所有执行 Agent 都应该读取同样的信息。用一份共享上下文承载这些差异，最终很容易演变成不断拆文件、复制文件、拼接上下文和维护权限规则。

所以问题并不是“Markdown 不够长”，也不是“共享文件夹还不够大”。

而是自然语言共享层本身缺少足够严格的结构来承载多主体协作。

共享事实、对象身份、关系、状态、规则、权限、视角和主体判断，需要被区分；它们之间哪些是一致的、哪些发生冲突、哪些只在某个视角下成立，也需要有更明确的表达方式。

这也是为什么，多主体协作最终需要的不只是更大的 shared context，而是一个更严格的结构化表征层。文本仍然可以存在，甚至仍然非常重要，但它不能独自承担全部语义对齐责任。

多主体协作的难点，不是让所有 Actor 看到同一份东西，而是让它们知道哪些东西是共同事实、哪些只是各自理解，以及彼此到底在哪些地方真正达成了一致。

一旦把环境单独拿出来，这个问题会清楚很多：共同事实由共享环境维护；不同 Actor 根据自己的角色、任务和权限获得不同视图；主体自己的判断仍然留在自己的认知状态中。多个主体可以针对同一个环境形成不同理解，而不需要因此复制出多个彼此漂移的“世界”。

协作并不要求多个 Actor 拥有完全相同的上下文，而是要求它们能够可靠地引用同一个共享现实。

04｜Harness 更像接口，而不是容纳整个世界的容器

现在普遍的演进方式，是继续往 Harness 里面增加能力：更多 memory、更复杂的知识库、更大的 working context、更强的 task state，最后希望 Harness 自己能够承载 Agent 所需要的一切。

但如果主体和环境本来就是两个不同的问题，那么 Harness 大概不应该无限扩张。

它更合理的位置，可能是在 Actor 与 Environment 之间。

主体一侧维护自己的记忆、技能、任务状态、假设和工作过程；环境一侧维护共享对象、关系、状态、规则、约束和事件。Harness 则负责让一个具体 Actor 能够感知环境、取得当前需要的表征、形成判断、执行动作，并把行动结果重新反馈给环境。

可以把它粗略理解成：

Actor ↔ Harness ↔ Environment

Harness 不需要“拥有”整个环境，就像人的感官和神经系统不需要把整个物理世界装进自己体内。它需要的是能够以稳定的方式接入环境。

这样一来，多主体协作也不再需要先解决“怎么把所有人的上下文同步成一份”。每个 Actor 可以拥有自己的记忆、视角和判断，通过 Harness 按照自身权限读取同一个环境，在需要协作时引用共同对象、共同状态和共同事实。

共享环境还可以提供一个比自然语言更严格的语义锚点。多个 Agent 即使拥有不同视角，也可以明确知道自己正在讨论的是同一个项目、同一个订单、同一个任务或同一条规则；分歧可以挂在共同对象之上，而不是散落在各自的 Markdown 中等待下一轮重新解释。

换句话说，共享发生在环境层，而不是通过复制主体内部状态来实现。

这也意味着，一些今天暂时存在于 Agent 本地工作区里的信息，未来可能会逐渐被外移。共享事实不应该成为某个 Agent 的私有记忆，组织级对象也不应该绑定在某一个 Harness 实现中。

该主体维护的归主体，该环境维护的归环境；Harness 负责二者之间稳定的感知、理解与行动接口。

这个边界可能比“未来 Harness 还应该增加哪些模块”更重要。

05｜真正的演进方向，是共享环境逐层向外扩展

如果沿着这个思路继续往外推，会发现 Harness 的演进并不一定意味着 Harness 本身越来越大。真正扩张的，反而可能是 Agent 所能接入的环境范围。

最开始，一个单 Agent 只需要维护自己的 memory、skill 和 task state，类似一个人管理自己的笔记和工作台。在这个阶段，很多上下文可以是私有的。

当多个 Agent 或人开始共同完成一个任务时，就会出现新的共享需求。但这里需要的不是让所有主体拥有完全相同的 memory，而是建立团队级的共享环境：大家围绕同一批任务、对象和状态协作，同时保留各自不同的视角、判断和权限。

继续往外，到了组织层，客户、合同、订单、项目、资源、职责、规则、指标这些对象不再属于某个团队。它们组成的是企业共同工作的数字世界。这里需要的已经不是更大的 Agent memory，而是企业级环境表征，也就是更接近企业 OS、Cognito Atlas 所处理的问题。

再往外，企业和企业之间还共享产品标准、供应链关系、行业规则、交易对象和公共语义。环境的 scope 继续扩大，最终会走向产业级的数字基础设施。

于是可以看到一条逐层展开的路径：

个人认知系统 → 团队共享环境 → 企业数字世界 → 产业数字世界

不同层级维护不同范围的现实，也对应不同的共享边界、视角和权限。Actor 根据自己的角色和任务接入其中，而 Harness 始终承担相似的职责：让主体能够与它所在的环境形成稳定的认知—行动闭环。

从这个角度看，下一代 Harness 的演进未必是成为一个越来越庞大的超级容器。恰恰相反，它可能意味着边界越来越清楚：主体维护自己的认知，环境维护共享的现实，Harness 负责二者之间的连接。

这也回到了我一直在关心的那个问题：

下一代 Agent，如何在长期、复杂、脏乱、持续变化的真实环境中保持认知一致性，并正确行动？

答案可能不只是给 Agent 更长的上下文、更大的 memory，或者让它记录更多 Markdown。

更根本的方向，也许是让 Agent 不必独自记住整个世界。