先做真实工具，再谈通用底座：IntentDNA 四个月后的路线重置

我先把结论放在前面：IntentDNA 当前产品路线失败了。

失败的不是“工作方法应该成为可复用资产”这个愿望，也不是过去四个月的所有研究和工程积累。失败的是我选择的产品建设顺序，以及一个未经验证就被当成前提的资产形态：我先建设了跨 Harness 的声明式工作流、编译器、Adapter、治理和 Online，再去寻找足以支撑这套平台的真实资产。

这篇文章不是一次产品宣传，也不是一次情绪化的告别。我想尽可能具体地说明：最初的愿望是什么，哪些判断仍然成立，我错在了哪一步，四个月的机会成本如何计算，以及接下来我会怎样用更低风险的顺序继续验证。

原始愿望没有变

四个月前，我想解决的问题不是“再做一个 Agent 框架”。

我看到 Claude Code、Codex 等通用编码 Agent 越来越强，但真正有价值的工作方法，仍然散落在个人经验、Prompt、对话记录、文档和临时脚本中。模型和工具会变化，一套经过验证的专业判断不应该跟着某个产品版本一起消失。

所以我最初的愿望是：

把工作流变成不依赖特定 Harness 的独立资产，让完成工作的办法可以被描述、复用、验证和持续改进。

这个方向里有一个判断是正确的：头部模型、通用编码 Agent 和 Agent SDK 的基础能力太强，我不应该自建通用 Agent runtime，也不应该重复实现模型循环、上下文管理、工具调用和基础执行框架。真正接近价值的位置应该是具体任务、专业判断和验证闭环。

问题出在我从这个正确判断继续推导了一步：既然不做通用 runtime，就应该先把工作流抽离成跨 Harness 的通用表示，再通过编译器和 Adapter 投放到不同执行环境。

现在看，这个推导没有足够证据。

工程完整性没有证明产品需要

沿着这条路线，IntentDNA 建立了声明式资产、编译器、IR、Adapter、Hooks、执行证据、组织治理和 Online 等完整的编译与执行面。它证明了一些技术判断：

• 工作流可以被结构化描述；
• 声明可以编译到不同执行表面；
• 软约束和硬约束可以分层；
• 执行证据、人工审查和改进建议可以形成闭环；
• 不同 Harness 的能力差异可以被明确表达。

截至 7 月 9 日的一次项目盘点，记录里已经有 1,879 项测试和约 105 份治理文档。这个数字能说明工程投入和系统完整度，但不能说明用户需要这一层。

七月的第一次重置已经暴露出问题：创作面和真实反馈不足。我用自己最熟悉的确定性工程，不断完善编译、约束和治理，却没有优先解决最困难的概率性问题：一个真实研发任务到底能不能被稳定完成，谁会持续使用，失败后如何恢复，它是否真的比人工流程更好。

更深的问题是：即使一个工作流值得成为资产，也没有证据证明它必须先从可执行程序中抽离，成为跨 Harness 的声明式表示。

我混淆了两件事：

1. 工作方法应该成为资产；
2. 工作方法必须先成为一种通用表示。

第一件事我仍然相信。第二件事需要退回假设状态。

为什么我一开始会走向工作流平台

IntentDNA 建立之初，我仍然主要用传统研发的知识结构理解 Agent。我知道不能重复制造通用 runtime，却以为只有精通模型循环、上下文、记忆、工具编排和各种 Agent 框架之后，才有资格直接做智能体应用。

在这个认知下，声明式工作流看起来更稳妥：它靠近我熟悉的编译、类型、约束和平台工程，也似乎能绕开 Agent 本身的不确定性。

这不是一个毫无根据的选择，但它暴露了我的能力偏好：面对陌生问题时，我优先建设了自己更容易控制的部分。系统因此越来越完整，真实任务却没有同步增加。

现在我的认识更具体了。Agent SDK 已经把第一个可运行版本所需的模型循环、工具调用、流式事件和执行控制压缩成了可用基础。一个有传统研发经验的人不必先成为 Agent 框架专家，才开始处理一个窄而真实的任务。

SDK 降低的是起步门槛，不是工程门槛。权限、状态、验证、恢复、成本和不确定性仍然要由研发人员负责。但这些问题应该在真实运行中被解决，而不是先被推演成一座完整平台。

四个信号改变了我的判断

最近四个信号共同推动了这次转向。我要先说明：它们是认知信号，不是严格的市场证明，也不足以单独证明新路线一定正确。

1. Agent 原理正在成为基础认知

ai-agent-book 的传播让我重新看待知识门槛。重点不是一本书本身能证明什么，而是模型不确定性、上下文边界、Tool schema、最小权限、人工确认和独立验证，正在从少数人的专门知识变成更广泛的研发基础认知。

我过去对“必须先成为 Agent 专家才能动手”的判断正在过时。

2. 面向具体任务的 CLI 是更自然的交付单元

我从一些行业交流中持续看到，大型研发组织内部存在大量面向具体任务的自动化 CLI。这里没有足够公开证据让我概括任何一家公司的完整实践，更不能据此宣布行业终局。

但它至少提醒我：研发资产不一定要先成为通用工作流语言。日志分析、环境诊断、测试归因、打包检查、发布准备和数据校验，都可以先作为独立工具创造价值。

3. 头部 Agent SDK 正在降低起步成本

不同 Agent SDK、通用编码 Agent 和 Harness 并不等价，它们在会话、权限、Hooks、沙箱、恢复和多 Agent 能力上都有差异。但我不再需要先解决这些产品之间的统一抽象，才能开始做一个任务工具。

我可以直接使用 Agent SDK，也可以借助 OMX、OMC 等现成工具在成熟编码 Agent 之上组织流程。具体选哪一种，应该由任务边界、调用方式和验证要求决定，而不是先由 IntentDNA 的统一表示决定。

4. 端到端能力正在变得紧迫，但专业边界没有消失

OPT（One Person Team）相关讨论，以及一次并不顺利的跨职能开发尝试，让我同时看到两件事：个人借助 AI 覆盖更长交付链路正在变得紧迫；通用 Agent 又不会自动提供仓库上下文、质量标准、权限边界、验证方法和异常处置。

这不是“任何人拿到聊天窗口就能替代专业岗位”。真正需要被封装的是由专业人员定义和维护的任务闭环：它知道收集什么上下文、允许做什么、如何验证完成、失败时留下什么证据，以及何时必须交还给人。

新的资产判断：专用 CLI 本身就是工作流

我现在更深的结论是：面向特定任务、可独立运行的 Agent SDK CLI，本身也可以是一份完整的工作流资产。

它可以拥有明确的任务边界、稳定输入输出、模型与工具、确定性程序、专业规则、人工确认点、测试与评估集、版本、负责人、安装方式、失败证据和恢复路径。

如果这些内容已经被封装在一个可独立运行的 CLI 中，就没有证据证明我必须先把它抽离成另一种表示，再适配回执行环境。

更合理的顺序应该是：

真实研发任务
  -> 专用 CLI
  -> 真实运行与评估
  -> 形成有效资产组合
  -> 从重复问题中提炼管理和治理
  -> 最终收口通用工作流底座（如果证据需要）

这不是永久放弃通用抽象。IntentDNA 的长期方向仍然可能收口为通用工作流底座，但抽象应该来自已经发生的重复：相似的接口、权限、评估、分发、调用和维护成本。它不应该来自我对未来平台的想象。

即使最终永远无法统一抽象也没有关系。每一个有效 CLI 已经独立创造了价值。相比之下，如果平台先行，而抽象长期没有被需要，平台本身很难兑现价值。

四个月的沉没成本不能被粉饰

我确实会想象另一条没有发生的路径：如果四个月前就围绕全栈和算法研发中的具体任务开始做 CLI，现在是否已经有日志分析、故障诊断、测试、打包、发布准备、数据检查和算法实验等一批闭环工具？

这是实际的机会成本。我不想用“所有经历都有意义”来掩盖它。过去四个月中，有一部分投入建立在尚未被证明的产品形态上。代码完整、抽象漂亮、测试很多，都不能替代真实使用。

但我也不会用一条想象中的时间线惩罚自己。没有证据证明另一条路线必然在四个月内产出一批成熟工具。可靠的 CLI 同样需要领域判断、权限边界、独立验证、失败恢复和持续 dogfood。

更有用的做法，是把过去四个月拆开处理。

继续保留的部分包括：

• 工作方法应该成为资产；
• 不自建通用 Agent runtime；
• 诊断、行为锁定、修复、验证和恢复是稳定工作流的核心；
• 模型自称完成不能作为完成证据；
• 权限、人工确认、执行证据和评估必须进入系统；
• 专业经验应该从个人操作变成可复用能力。

降级为待验证假设的部分包括：

• 工作流必须先成为跨 Harness 的声明式资产；
• 当前就需要统一 DSL；
• 当前就需要完整的资产市场、组织治理和 Online 控制面；
• 新工具必须先接入 IntentDNA 才能被称为资产。

沉没成本已经发生。真正危险的不是承认路线失败，而是为了证明过去没有走错，再投入下一个四个月。

下一阶段：一个任务，一个闭环

下一阶段我会聚焦全栈和算法研发流程，从一个个真实任务开始打造 CLI：日志分析、诊断、测试、打包、发布准备、数据检查、算法实验及结果分析。

选择任务时，我会坚持四个条件：真实重复、边界清楚、结果可证、风险可控。第一版不追求通用，也不追求生产级，只要求能够在受控环境中稳定结束一件真实工作。

不是所有 CLI 都需要 Agent：

目标是闭环，不是 Agent 使用率。

没有评估的 CLI 只是个人实验

CLI 能运行，不等于它已经成为团队资产。我的最低判断是：

没有评估的 CLI 只是个人实验；具有任务契约、评估集、运行证据和负责人的 CLI，才可能成为团队资产。

评估对象不是模型的一段回答，而是输入、上下文、Prompt、模型、工具、确定性代码、权限、验证器和失败处理共同组成的系统结果。

下一阶段最重要的指标包括：

• 任务成功率：机器证据确认真正完成的比例；
• 错误成功率：工具声称成功、实际失败的比例；
• 非计划人工介入率：设计内审批以外，需要人工继续推动或修复的比例；
• 恢复率：失败后能够从现有证据和状态继续的比例；
• 耗时：模型执行、工具等待和人工复核的总时间；
• 成本：模型、基础设施和人工复核成本；
• 回归率：代码、Prompt、模型、SDK、工具或验证器变化后，旧案例重新失败的比例。

其中我最警惕错误成功率。一个工具明确报告失败仍然可控；一个工具错误地报告完成，会把风险隐藏到发布、数据或后续交付里。

信任顺序也应该保持清楚：测试、构建产物、目标系统状态和规则检查，优先于结构化人工审核；结构化人工审核优先于 LLM-as-judge；主执行 Agent 的自我评价不能作为最终证据。

技术会改变岗位，专业责任不会自动消失

把专业经验做成工具，自然会带来“我会不会被替代”的担忧。我不打算承诺“只要不想被替代就不会被替代”。技术会改变岗位和协作边界，这件事不能靠口号否认。

更诚实的目标是减少重复执行，让专业人员把精力移到问题定义、边界设计、结果验证、异常处理和工具演进。能够调用一个 CLI，不等于能够定义它的适用范围、判断结果是否可信、处理未覆盖的异常，或为关键结果承担责任。

专业人员仍然要负责：

• 决定什么问题值得自动化；
• 定义必要上下文、权限和安全边界；
• 设计完成证据与回归评估；
• 处理自动化无法覆盖的异常；
• 维护、升级和停止不再有效的工具；
• 对工具产生的结果承担专业责任。

工具会扩散执行能力，责任不会因为入口变简单而自动消失。

IntentDNA 接下来是什么

现阶段我会冻结未经验证的横向平台扩张，不要求新的 CLI 接入完整 IntentDNA 表示，也不把跨 SDK 兼容当成第一阶段目标。

IntentDNA 会保留评估、证据、诊断、权限、验证和恢复这些经验，观察首批真实 CLI 反复遇到的问题。只有当资产发现、调用契约、权限、评估、分发或维护确实形成重复成本时，才提炼公共组件、管理协议和治理能力。

因此，“IntentDNA 当前产品路线失败了”和“IntentDNA 最终仍可能收口通用工作流底座”并不矛盾。前一句是在否定平台优先的建设顺序和资产形态假设；后一句必须以真实资产和重复问题为前提，而不是提前兑现。

历史路线不会被删除。IntentDNA Lab 会继续保留原来的 compiler、Harness 治理和八篇文章，作为一段可以追溯的研究记录。它们不再代表当前已经被验证的产品定位，但其中的方法和问题仍然值得复核。

接下来我不再用平台规模证明方向。我会用一个个任务的真实运行、失败样本、评估结果和持续使用，决定哪些东西值得留下，哪些抽象应该出现，以及 IntentDNA 最终需要成为多厚的一层。