从 Domain Workload 到垂直领域 Agent

从 Domain Workload 到垂直领域 Agent

为什么 Skill 暴露 Domain、Harness 承载 Workload，而 Agent Runtime 才是缺失的那一层

究竟是什么成为了 Agent？

Codex、Claude 以及其他通用 Agent，已经能够跨越大量不同的 Domain 进行推理、使用工具并快速适应新任务。给它们增加一个 Skill，它们便可以遵循某种专业词汇和领域方法；再为这些工作增加一个 Harness，同一种方法就可以在工作流中重复执行、接受审阅，并在失败后恢复。

但此时，究竟是什么成为了 Agent？

是负责推理的模型？描述方法的 Skill？承载状态的 Harness？还是它们恰好相遇的那一次 Session？

只要其中任何一部分发生变化，这个问题就不能回避。模型会升级，Skill 会被改写，Harness 会被迭代甚至替换，Session 更一定会结束。如果一个 Domain 还要继续学习、继续工作并继续为自己的行为负责，就必须有某种东西能够跨越这些变化，仍然保持可识别。

Skill 可以让通用 Agent 具备领域能力，Harness 可以让工作变得可重复，但两者单独都不能让 Domain 成为持久 Agent。

这就是本文真正要回答的架构问题：一个 Domain 还需要什么，才能成为一个真正独立存在的 Agent？

我目前的答案是 Agent Runtime。它不是 Tool Loop 的另一个名字，也不是包在模型外面的一层 Wrapper，而是一个组合与连续性层：受治理的 Domain workload 通过它，才有可能逐渐成长为一个持久行动主体。

通用智能不等于 Domain Continuity

通用 Agent 最重要的优势是广度。它可以进入一个陌生问题，理解新的材料，发现可以调用的工具，并完成有价值的工作，而不需要为每一个领域分别训练一套模型。本文的论点并不削弱这种能力。

但是，进入一个 Domain，并不等于作为这个 Domain 持续存在。

一次成功的研究任务，不会自动建立持久的研究主体。一次正确的合规分析，不会自动决定谁可以批准下一次政策变化。一次已经完成的发布任务，也不会自动说明哪些证据应被保留、哪些知识已经被接受，或者中断后的操作应该如何继续。

一个 Domain 不只有词汇。它还有自己的运行方法、质量规则、accepted knowledge、Authority boundary、Evidence 标准，以及特有的失败模式。当当前模型、Session 或执行宿主发生变化时，这些内容仍然需要保持一致。

在本文的架构里，通用 Agent 可以承担 Domain workload 的推理与执行宿主；但逻辑上的 Domain Agent 不能被简化成下一步恰好由哪一个宿主执行。它的连续性必须存在于别处。

把 Domain 带入通用 Agent 的第一种常见机制，通常就是 Skill。

Skill 暴露 Domain

Skill 为通用 Agent 提供了一种带有 Domain 形状的理解与行动方式。

它可以引入真正重要的领域词汇，区分事实与解释，编码决策规则，描述任务方法，发现正确的工具，并建立稳定的交互 Contract。设计良好的 Skill 绝不是一个装饰性 Prompt；它是 Domain semantics 与领域实践的一种可执行表达。

这正是 Skill 如此重要的原因，也是为什么把 Skill 直接称作完整 Domain Agent 仍然过快。

默认情况下，Skill 并不会回答所有连续性问题：究竟是哪一个持久 Identity 在调用它？它的 Authority 是否能超越当前这一次调用？谁拥有任务之外的完整 lifecycle？哪些结果可以跨运行成为 accepted knowledge？当执行中途停止时，Evidence、terminal Receipt 与 Recovery state 又在哪里？

Skill 完全可以参与这些机制，甚至可以负责发现或协调它们。关键区别在于：Skill 首先定义的是如何理解这个 Domain，以及一类任务应该怎样完成 ；它不一定同时定义哪一个获得授权的主体会在调用结束后继续存在。

所以，Skill 把 Domain 暴露给一个有能力的通用宿主，让宿主具备领域能力。当工作必须跨越时间、状态、Approval 与失败而重复发生时，另一层就会显现出来：Harness。

Harness 承载 Workload

Domain workload 比单个任务更大。它包含任务本身，也包含 lifecycle state、Knowledge operation、Evidence、Approval、terminal outcome 与 Recovery behavior。

Harness 承载的正是这套具体 workload。

它可以编排 Control Flow、冻结 Plan、绑定 Evidence、执行 Human Gate、调用确定性服务、记录 Receipt，并在操作中断后判断：现在可以安全恢复，可以通过 checksum 等证据进行 reconciliation，还是必须回到人工决策。Harness 把一种有用的方法变成可检查、可重复的运行生命周期。

这已经远远超过一次 Skill invocation，但它仍没有自动解决 Identity 问题。

Harness 为某一种 workload 实现承载运行状态。它可以被升级、迁移、拆分或者替换；它的职责，是让生命周期具体而可靠。这并不要求它拥有全部 Domain meaning、全部 accepted knowledge，或者拥有一个应该超越 Harness 本身而继续存在的永久 Identity。

这也回应了一个最强的反对意见：如果 Harness 调用了 Runtime 并且承载状态，为什么不直接把 Harness 称为 Agent？

某些系统当然可以这样命名。但从架构上看，调用服务与承载 lifecycle state 还不充分。Workload carrier 不会自动成为那个持久主体------Capabilities、Authority、Knowledge relationship、Evidence history 与未来演进需要共同附着在这个主体上。

Skill 加 Harness，已经给出了领域能力与可重复运行；此时仍然缺少的，是一个持久行动主体。

缺失的是持久行动主体

如果不再争论哪一个组件"看起来最像 Agent"，而是追问连续性究竟附着在哪里，这个缺口会更清楚。

哪个 Identity 正在行动？哪些 Capability 和 workload 属于它？它可以读取或改变哪些 Knowledge？哪些 Evidence 会跨越一次执行而保留？谁可以批准语义变化？中断以后由什么继续 Recovery？当 Model、Skill、Harness 或 Host 发生变化时，什么仍然保持可识别？

如果这些答案分散在临时 Session 和各个组件自己的约定里，那么 Domain 仍然只是一个被挂载的 workload。它可以很强大，但还不是一个持久主体。

我给出的最小定义是：

Vertical Domain Agent 是一个持久且受治理的 Agent Identity，它把 Domain 语义、可重复 workload、持久知识、Authority boundary、Evidence、Recovery 与人工监督下的演进组合在一起。

这里的"Identity"不是给软件塑造人格，也不是主张它拥有法律主体地位，而是一个稳定的运行主体：系统能够命名它、授权它、检查它、继续它，并要求它遵守某种 Contract。

这个 Agent 也不需要拥有全部 Domain knowledge。许多时候，那反而是错误的边界。Accepted knowledge 可以继续归属于 Domain，并被多个获得授权的 Agent 复用。真正附着在 Agent 上的，是它的 Identity、Memory intent、workload binding、Authority、Evidence trail，以及它与 accepted knowledge 之间持续存在的关系。

到这里，Agent Runtime 就不再只是基础设施管道。它为这些关系提供了一个共同的落点。

Agent Runtime 是组合与连续性层

Agent Runtime 是一套通用系统：它把 Domain capability 与 Domain workload 绑定为一个能够持续存在的 Agent，同时不会把所有责任压缩进同一个组件。

我更愿意用六个问题来定义这套 Runtime：

• 谁在行动？ 持久的 Agent Identity，以及它在系统中的 Principal representation。
• 它能做什么？ 与它绑定的 Skill、Tool 与 Capability。
• 它正在承载什么工作？ Domain workload 与 lifecycle contract。
• 它可以知道或改变什么？ Knowledge scope、trust policy 与 Mapping authority。
• 发生过什么？ Evidence、Log、Approval 与 Receipt。
• 它如何继续？ Recovery、Replay、Migration 与 controlled evolution rule。

此时，各个角色的边界会变得清晰。

Skill 提供 Domain semantics 与 task method；Harness 定义并承载具体 Domain lifecycle；Agent Runtime 提供可复用的 Identity、Binding、Governance、Evidence 与 Recovery contract；Human 或 Domain owner 则保留 semantic acceptance，以及批准重要变化的最终 Authority。

这是 Composition，而不是 Consolidation。Runtime 不应该把所有 Skill 吞进一个万能 Prompt，不应该替每一个 Domain 定义具体生命周期，更不应该宣称自己拥有 Domain truth。它的工作，是让这些可以分别演进的部分，能够作为同一个受治理主体协同工作。

它也改变了"可移植性"的含义。目标不应该是让每一个宿主都表现得完全相同。更强的目标是：即使推理由不同模型或不同执行宿主提供，Domain Agent 仍然能够通过 Identity、Contract、Knowledge relationship 与 Evidence 保持可识别。

这仍然是 North Star，而不是已经在 Codex、Claude 与所有未来宿主上完成验证的结论。

Agent Runtime 不会自动把任意 Domain 变成 Agent。它提供的是基础设施与 Contract，使受治理的 Domain workload 可以向一个持久 Agent 演进。

Agent Runtime 组合 Identity、Capability、Workload、Knowledge authority、Evidence 与 Recovery，同时保持周围角色的边界。

Knowledge 是一个 Plane，而不是完整 Runtime

持久知识对这种连续性至关重要，但它只是更大 Runtime 内部的一个 Plane。

在这条研究主线中，llm-wiki-runtime 承担的是受治理 Knowledge Plane。它所处理的"Memory"，不是不断膨胀的对话历史，而是获得授权的 Principal 与 accepted Domain knowledge 之间的确定性关系。

这包括 bounded、Catalog-first Query，exact lookup 与 load，来源与 Contract validation，Principal 与 Mapping authorization，controlled write 与 promotion，以及可以被多个授权主体复用的 accepted record。Runtime 负责执行知识怎样跨越边界，却不负责决定 Domain 应该相信什么。

这里的责任划分是刻意的：

• Skill 解释 Domain meaning，并提出知识应该怎样参与任务；
• Harness 把 Query、Review、Promotion 与 Recovery 放进具体 workload；
• Knowledge Plane 确定性地执行 Access、Authorization 与 Persistence；
• Human 或 Domain owner 接受 semantic change。

集成 Contract 对这个边界给出了明确表达：Harness 拥有 Plan、Digest、Gate、Receipt 与 Recovery，而 Runtime 拥有 validation、受控存储操作、路径边界、锁与原子持久化。

因此，llm-wiki-runtime 不是完整 Agent Runtime。它提供的证据是：Runtime 中一个关键 Plane 可以被显式建模、接受治理并被复用，而 Skill 与 Harness 都不需要因此直接拥有知识存储。

第一个实现案例说明了为什么这种关系必须穿过工作流时间，而不仅是一次调用。

案例一：跨越工作流时间的连续性

Research Publishing Harness 是第一个很合适的案例，因为发布并不是一次模型调用。它是一条 Artifact 状态不断变化的序列，而每一次变化都需要保持可检查。

仓库把 Harness 描述为围绕 AI-assisted research and writing 的确定性控制层。模型可以参与调查与起草；Harness 则拥有 Evidence、Gate、已批准内容、发布状态、Receipt 与 durable-knowledge promotion（来源）。

它与 llm-wiki-runtime 的集成是可选且显式的，并在这个实现中精确绑定 Runtime 0.2.0。关键不在于 Runtime 是否出现在每一个 lifecycle node------事实上并没有。Runtime-backed operation 只在更大 Publishing workload 内部那些边界明确的 Knowledge operation 节点发生。

这条受治理循环大致是：

Catalog-first Query → reviewed Context → Package → terminal Evidence → Semantic Delta → Human Review → approved Promotion → Runtime writes 与 Catalog-last visibility → next Query

这个序列记录在仓库的 memory loop 中；仓库也包含一项针对固定 JSON CLI 边界的真实 Runtime 集成测试。

对我来说，第一个 Harness 改变的是问题的时间边界。Knowledge continuity 必须穿过一系列受到治理的状态，而不是只存在于一次执行中。Proposal 不是 accepted claim，Submit action 不是 verified publication，Feedback 也不会自动成为 durable knowledge；每一次状态转换都需要 Evidence 与显式 Boundary。

这个案例能够说明：Harness 可以跨越时间承载 Domain workload，同时使用受治理 Knowledge Plane。它没有说明每一种发布工作流都需要这个 Runtime，没有说明 Harness 已经是完整 Vertical Domain Agent，也没有说明这项集成已经提升发布质量或业务结果。

但时间连续性只解决了一半问题。第二个案例暴露的是 Identity 与 Authority。

案例二：跨越权限边界的 Identity

AI Research Observatory 让下一个边界变得更具体：两个行动主体可以共享 accepted Domain knowledge，却不需要共享 Identity 或写入 Authority。

在当前 Runtime 0.3 集成中，Observatory Harness 拥有独立 Principal ID：ai-research-observatory-harness，并被表示为 kind: workload、role: domain_harness（Principal contract）。Skill 是另一个独立且可选的 interaction Principal；即使 Skill 没有安装或注册，Harness 仍然可以运行（责任边界）。

两个 Principal 都可以查询同一条已接受的 research_direction_revision。但 Mapping 只归 Harness Principal 所有（Mapping contract）。当 Skill 试图借用这个 Mapping 进行写入时，Runtime 返回 mapping_owner_mismatch，已有 Record 的 checksum 保持不变。

这不只是设计文档中的一句声明。仓库的跨仓库端到端测试 实际覆盖了 Principal 共存、共享读取、拒绝写入与 Record 不变这条路径。Runtime 仓库还保存了一份不可变的 Observatory reference example，用于复现同一边界。

对我来说，第二个 Harness 改变的是问题的 Authority boundary。Domain workload 不能再被当成一次 Skill invocation；它需要独立受治理的 Runtime Identity。即使相邻 Principal 能够读取同一份 accepted knowledge，也不能借走它的 Authority。

这个案例能够说明：Workload 可以成为 Runtime 中具有不可转移 Authority 的 first-class subject。它没有说明每个 workload 都必须拥有独立 Principal，没有说明 workload/domain_harness 已经是最终 Agent Identity model，也没有说明 Observatory 已经是可移植、完整的 Vertical Domain Agent。

从两个局部证据走向一个 North Star

两个案例提供的是不同维度的证据。

Research Publishing Harness 提供了时间与 lifecycle 维度：Domain workload 可以跨越一系列操作，保留受治理的 State、Evidence、Review、Promotion 与 Recovery。

AI Research Observatory 提供了 Identity 与 Authority 维度：Domain workload 可以作为独立 Principal 运行，与 Skill 共享 accepted knowledge，同时仍然保留不可转移的写入所有权。

Agent Runtime 是我们提出的组合层：它把这两个维度进一步与 Capability、Knowledge、Evidence 和 Recovery 绑定起来。

我们的 North Star 是这样的 Vertical Domain Agent：当模型与宿主发生变化时，它仍然保持可识别；它承载可重复、可检查的 Domain workload；它与 accepted knowledge 之间存在受授权的关系；它产生显式 Evidence 与可恢复 State；它的语义只在恰当的人工监督下演进。

任何一个仓库都没有实现这个完整 North Star。即使把两个仓库放在一起，也不能证明普遍可移植性，更不能宣布 Agent 架构已经完成。它们是两个边界清楚的实现案例，使一些原本抽象的组成部分变得可观察。

一个保持克制的结论，反而更有力量：

当前实现说明 Domain workload 可以成为 Runtime 中 first-class、受治理的主体，并为 Skill / Harness 集成走向持久 Vertical Domain Agent 提供局部证据。

两个实现案例为更大的 Agent Runtime 架构提供局部证据；North Star 仍未完成。

这套架构没有声称什么

这套架构没有声称 Skill 已经是 Domain Agent，也没有声称 Harness 会自动成为永久 Agent 主体。它不要求 Agent Runtime 定义每一种 Domain lifecycle，也不把 llm-wiki-runtime 说成完整 Agent Runtime。

它同样没有声称当前项目已经是成熟的 Vertical Domain Agent。跨 Codex、Claude、其他模型家族与未来执行宿主的可移植性，仍然是需要验证的假设。质量、效率、成本与商业价值方面的结论，也都还没有在本文中得到证明。

这些区别本身就是本文的重点：

• Skill 暴露 Domain。
• Harness 承载 Domain workload。
• Agent Runtime 提供让 workload 获得持久性的通用 Contract。
• Human 或 Domain owner 保留 semantic authority。

当前仓库只为其中一部分组成提供了实现证据：有边界的 lifecycle continuity、受治理的 Knowledge operation、独立 Principal Identity，以及不可转移的 Mapping authority。它们并没有终结这条研究主线。

Vertical Domain Agent 仍然是 North Star。下一步需要验证的是：当我们加入更多 Domain、更多 workload、更多宿主，以及多个 Agent 共同使用一份 accepted knowledge 时，这些 Contract 是否仍然成立。

下一个 Agent 可能就是一个 Domain

我们的目标不是让通用 Agent 变得不再通用，而是让它们的智能更容易进入一个具体 Domain，同时不让这个 Domain 依赖某一个模型、某一个 Skill、某一个 Harness 或某一次 Session。

这会改变我们真正要培育的单位。我们不再只是反复教通用 Agent 完成一个个孤立的 Domain task，而是开始追问一个 Domain 本身如何获得连续性：可识别的 Identity、受治理的 workload、与 Knowledge 之间获得授权的关系、Evidence trail、Recovery，以及一条可控的演进路径。

因此，这条研究主线的锚点可以被压缩成一句话：

Skill 暴露 Domain，Harness 承载 Domain workload，Agent Runtime 则赋予这个 workload 成长为持久 Vertical Domain Agent 所需的连续性。

本文中的仓库是早期且边界明确的证据，而不是终点。更深的问题仍然开放：

具体 Domain 能否在不重复重建 Identity、Knowledge、Governance、Evidence 与 Recovery 的前提下，逐步成长为持久 Agent？