OPEN SOURCE DEEP DIVE
HelixHarness：把团队工程基因带进编码智能体
滴滴开源的编码智能体运行时，用 Propose、Apply、Archive 把需求、验证与可复用工程知识留在仓库，并提供可选的观测、版本评测与人工把关的进化平台。
HelixHarness 是滴滴金融科技团队开源的一套编码智能体运行时。它并不试图再发明一个通用编码模型，而是把团队已经形成的业务规则、架构边界、验证方式和历史经验整理成编码智能体能够按需读取的项目上下文，再用一条可检查的研发流程约束需求、实现与归档。当前源码标注 HelixHarness 与 helixharness-platform 均为 1.0.0 版本，采用 Apache-2.0 许可证；本文基于仓库提交 8b23069fb464104ce556798ec69737f7eba469b3 精读。
项目最值得关注的地方，是它把“知识复用”和“框架自身如何改进”拆成了两个边界清楚的产品：前者是安装在 Codex 或 Claude Code 中、直接服务业务研发的插件；后者是维护者可选部署的观测、评测与进化平台。普通开发不依赖平台在线，平台也不被描述成给业务代码打分的通用服务。
不是提示词集合，而是可恢复的研发生命周期
HelixHarness 对外提供九个公共命令：init、propose、apply、archive、bug-fix、ut、update、status 和 config。核心路径是 Propose、Apply、Archive。Propose 明确需求范围与验收条件，生成规范与任务；Apply 执行实现、测试和双轴评审；Archive 检查完成证据，并将确认过的经验整理回项目知识。
这里的“完成”由仓库中的工件和验证结果决定，而不是由模型回复“已经完成”决定。需求、任务、验证报告和归档结果都留在项目里，因此开发者可以审阅过程，也可以在中断后恢复未完成工作。propose --loop 能连续推进三个阶段，但遇到需求决策、验收边界或真实阻塞时仍会暂停。项目文档还明确区分研发完成与发布部署：这条循环本身不负责上线。
单仓模式和多仓 Workspace 共用业务合同。Workspace 在根目录维护仓库关系与依赖编排，每个参与仓库仍保留自己的需求、实现、测试和验证证据；根目录不会代替子仓写业务工件。这种设计让跨服务功能有一个统一的协调入口，同时避免把多个仓库的生命周期混成一份无法审计的巨型任务。
把 Harness、Knowledge、Specs 和 Hooks 分开
HelixHarness 将项目上下文分成四个层次。Harness 回答“代理必须遵守什么工程约束”，存放在 docs/harness/；Knowledge 回答“系统如何运作、哪些业务规则和历史决策重要”，存放在 docs/knowledge/；Specs 回答“当前要构建什么、用什么证据证明完成”，存放在 docs/specs/；Hooks 则把宿主运行时检查、流程门禁和评审清单接到关键阶段。
这种拆分让不同类型的上下文拥有不同生命周期。业务规则可以在 Archive 后沉淀，任务合同随着当前需求结束，执行检查跟随宿主和项目配置变化。它们不是被一次性塞进超长提示词，而是通过 index.md 的“文件或目录、定位、加载时机”三列表格按需选择。代理先读取根索引，再只加载当前需求、任务或归档步骤真正命中的叶子文件。
按需加载协议还规定了一个容易被忽视的边界：未被索引的内容不属于标准读取集，代理不能凭文件路径猜测并跳过索引直接读取。这减少了“碰巧读到一个旧文档”带来的上下文污染，也迫使项目维护者把真正可复用的知识整理成有导航、有加载条件的资产。
宿主适配与共享核心的边界
HelixHarness 当前以稳定支持等级接入 Codex 和 Claude Code。共享核心保存工作流顺序、任务状态、检查点、工件合同和评审门禁；Host Kit 负责命令投影、原生工具映射、子代理派发、项目设置、Hook 生命周期、遥测和更新。Codex 使用 Skill 投影，Claude Code 使用原生命令，但两者都必须指向同一套公共命令合同和唯一阶段正文。
Host API 1.1 的价值在于阻止平台差异渗入业务逻辑。若某个宿主缺少能力，适配器必须明确声明原生、模拟或不支持；没有安全降级时应关闭失败，而不是偷偷借用另一个宿主的路径。新增宿主也被要求作为独立的架构变更完成清单、安装、运行时适配和真实客户端验收，不能在共享核心中增加平台名称分支。
这种边界同样体现在 Hook 分发上：Codex 与 Claude Code 各自声明自己的 hook 配置，共享生命周期服务只消费显式 HostManifest 和规范事件，不根据环境变量或缓存目录猜当前宿主。会话停止也不会被当作业务任务已经完成，阶段完成需要显式记录 start 与 finish。
可选平台：观测、评测与候选进化
helixharness-platform 是面向框架维护者的可选服务，采用 FastAPI、Jinja2 和 HTMX。组合 Web UI 连接三个互不导入、也不跨模块查库的部分：Bench 管理标定用例与隔离执行，Eval 连接冻结版本、验收测试和评审结果，Evolution 从符合条件的证据中生成候选假设。每个模块拥有独立数据库，平台服务不是插件运行的前提。
评测对象是 HelixHarness 框架版本或候选变更，而不是业务代码本身的优劣。基准与候选必须由明确的 Git 引用冻结，在同一批已发布且经过校准的 Case 上运行，并由独立 Worker、确定性检查与模型评审共同形成证据。候选审阅通过后才进入评测，平台也不会自动发布候选。
项目对证据边界写得很克制。内置 Demo 使用合成 Case、Mock Run 和项目账本，页面会明确标注 Demo，不能把其中的分数当作模型性能或框架改进幅度。真实评测需要使用者配置模型服务、凭据、可访问仓库和经过校准的 Case。遥测默认关闭，异步上报与反馈也没有默认平台地址；即使设置了地址，反馈内容仍需要用户确认。
适合谁，以及当前不应误读什么
HelixHarness 适合希望把团队工程习惯、业务知识和评审门禁带进编码代理研发流程的团队，尤其是需要跨多个服务协作、保留任务证据或维护自有智能体框架的组织。它提供的是一个可以审阅和扩展的运行时骨架，而不是“配置后自动完成所有软件工程”的承诺。
当前边界同样清楚：只正式支持 Codex 与 Claude Code；多代理宿主支持和可配置工作流阶段仍在路线图中；真实评测依赖外部模型环境与标定 Case；知识是否进入长期资产仍由人确认；候选是否采纳也由人决定。正是这些限制，让项目更像可审计的工程基础设施，而不是又一个用模型回复掩盖过程风险的自动化外壳。
源码与完整文档位于 didi/helixharness，许可证为 Apache-2.0。对于正在构建 Agent Harness、编码工作流或团队知识系统的开发者，它提供了三个值得单独审视的设计：阶段工件作为完成证据、索引驱动的上下文加载，以及宿主适配与框架评测之间的明确分界。