IntentDNA 的核心，不是替代 harness，而是治理 harness。
如果第一篇文章讲的是个人生产力路线：skill -> workflow -> agent，那么这篇文章讲的是系统路线： intent -> policy -> IR -> adapter -> harness -> evidence。
我现在越来越确定，IntentDNA 不应该成为唯一 harness。它不应该强迫所有人离开自己熟悉的工具， 也不应该一开始就重写 Codex、Claude Code 或 OpenAI Agents SDK 已经做得很深的运行时。
它真正有价值的位置，是作为一套治理语言和编译层：把人和组织的意图、边界、角色、workflow、权限、 验证标准和证据要求，编译到不同 harness 能理解、能执行、能审计的控制点里。
IntentDNA 不应该成为唯一 harness；它应该成为 harness 的治理语言。Samuel Wang / IntentDNA thesis
越多 agent 进入公司，治理语言越重要。
今天一个团队可能同时使用 Codex Desktop、Claude Code、Cursor、OpenAI Agents SDK、内部脚本、 MCP server、CI agent 和浏览器自动化。每个工具都有自己的 prompt、权限、工具调用、trace、state、 memory 和 approval 机制。
如果没有一层统一语言，公司最后会得到一堆局部自动化：每个工具都能做事，但组织无法回答这些问题： 谁允许它这样做？它依据哪条策略？它有没有越过项目边界？失败后谁接手？结果怎么验证？下次如何复用？
工具会越来越强
OpenAI Agents SDK 已经把 turns、tools、guardrails、handoffs、sessions、tracing 放进运行时。 LangGraph 也把 long-running、stateful agents 作为核心方向。
组织会越来越碎
工具越强，局部自治越多。没有统一意图和证据层，团队会获得更多自动化，也获得更多不可解释的行为。
为什么我不想一开始就自建 agent runner？
自建 runner 很诱人，因为它看起来能控制一切。但现实是，一个生产级 harness 要处理的事情非常多： 工具 schema、权限、沙箱、上下文压缩、状态持久化、错误恢复、人工介入、trace、评估、重试、并发、 预算、审计和 UI 交互。
如果我现在把全部精力投到自建 runner，IntentDNA 很容易变成一个“又一个 agent framework”。 这不是我想要的位置。未来会有很多优秀 harness，模型厂商、IDE、云平台和企业内部系统都会继续演化。 真正更长期的价值，是站在它们上面，定义组织意图如何被声明、传递、执行和证明。
我的产品判断是：入口应该尊重用户习惯，治理层应该保持独立。用户习惯 Codex Desktop，就不该要求他先迁移到我自己的 runner。
IntentDNA 应该像编译器，而不是像聊天框。
编译器的意义，是让高层意图落到低层执行面。IntentDNA 的高层语言描述的是组织想要什么、禁止什么、 谁能做什么、什么时候要验证、什么结果可以进入证据系统。底层 adapter 再把这些内容映射到具体 harness。
治理不能只靠 prompt，它必须有多层控制面。
prompt 是必要的，但不是充分的。真正的生产环境里，软约束会被上下文压缩、用户覆盖、工具边界和模型不稳定性削弱。 所以 IntentDNA 需要把同一条组织意图拆到不同层级。
| 层级 | 适合表达 | 风险 | IntentDNA 编译目标 |
|---|---|---|---|
| Prompt | 行为偏好、角色语气、工作原则、提醒。 | 容易漂移，可能被压缩或覆盖。 | AGENTS.md、CLAUDE.md、system prompt additions。 |
| Tool Gate | 工具允许/拒绝、路径范围、敏感操作确认。 | 不同 harness 支持不一致。 | hooks、permissions、SDK tool guardrails、CI wrapper。 |
| Workflow State | 阶段、产物、handoff、验证前置条件。 | 如果只在对话里，很容易丢。 | state files、sessions、checkpoints、artifact manifests。 |
| Evidence | allow/warn/block/escalate/validate 的来源和理由。 | 普通日志难以成为治理证据。 | RuntimeDecisionEvent、trace、audit report。 |
adapter 不是附属功能，而是 IntentDNA 的现实路线。
如果 IntentDNA 真的要成为跨 harness 的治理语言，那么 adapter 必须是一等公民。每个 adapter 都应该回答： 这个 runtime 支持什么？不支持什么？哪些只是软约束？哪些可以硬拦截？哪些能产生证据？
这也是我为什么强调 capability matrix。没有 matrix，就会把“理论上能治理”误写成“实际上能治理”。 在公司场景里，这种差异非常危险。
不能映射的能力，要写 unsupported；不能假装支持。IntentDNA adapter contract principle
公司大脑不是更大的聊天机器人，而是跨 harness 的工作系统。
如果公司未来有很多 agent，真正的问题不是“哪个 agent 最聪明”，而是这些 agent 如何继承同一套组织意图。 它们应该知道哪些事情能做、哪些事情要升级给人、哪些结果必须验证、哪些决策要记录、哪些上下文不能丢。
所以公司大脑不是一个问答入口。它应该像一个组织操作层：管理知识、workflow、任务、权限、事件、证据和复盘。 IntentDNA 的长期价值，是给这个操作层提供语言、编译器和证据标准。
从个人 workflow 开始，才有资格谈组织治理。
我不认为这条路可以直接从“企业控制面”开始。没有真实 workflow，就没有真实治理语言。没有自己 dogfood， 就很难知道哪些约束是有用的，哪些只是漂亮概念。
所以 IntentDNA 的建设顺序应该是：先把个人 AI-native 工作流做扎实，再抽象 skill 和 workflow 模型； 然后做 Codex-first adapter；再扩展到 Claude/OpenAI/LangGraph 这类 rich harness；最后才是组织级控制面。
我会把 IntentDNA 当成一门“组织意图编译语言”来推进。
- 先沉淀个人高频 workflow，避免抽象领先证据太多。
- 用 Codex-first 路线尊重真实使用入口，不强迫迁移。
- 每个 adapter 都必须有 capability matrix 和 unsupported 列表。
- 每一次 allow/warn/block/escalate 都要能回到策略来源。
- 最终目标不是控制模型，而是让组织意图能跨 harness 可靠执行。
这条路线和主流工程实践正在同向。
我选择这些来源，是因为它们分别代表模型厂商、agent SDK、stateful workflow 框架、协议层和市场趋势。 它们共同说明：agent 的竞争点正在从“能不能调用模型”转向“能不能被运行、治理、追踪和集成”。
Anthropic 区分 workflow 与 agent，并强调从简单、可组合的模式开始，而不是先上复杂框架。
OpenAI 的 Agent + Runner 把 turns、tools、guardrails、handoffs、sessions 放进 orchestration 语境。
SDK tracing 覆盖 LLM generations、tool calls、handoffs、guardrails 和 custom events，说明证据链是生产要素。
guardrails 和 tripwires 体现了 harness 中确定性控制面的重要性。
LangGraph 定位为 long-running、stateful agents 的低层编排框架，强调 durable execution 和 state。
MCP 把上下文、工具和外部系统连接标准化，说明未来 agent ecosystem 会走向多工具、多 runtime 集成。
McKinsey 看到 AI 使用普及，但企业收益仍受 workflow 嵌入、治理和规模化能力制约。
Bessemer 从资本视角描述 AI-native development 和 agentic systems 的复利机会。