从模型到企业交付：Harness 到底补上了哪一层

大语言模型最核心的能力，是根据输入生成下一个合适的输出。它可以表现得很聪明，却天然不知道你的文件在哪里、公司允许它访问什么、上一轮工作做到哪一步，也不会自动为失败留下恢复线索。即使模型本身完全不变，换一套工具、记忆、提示组织和错误恢复方式，最终体验也会像换了一个人。

因此，评价一个 Agent 产品时只比较模型排行榜，等于评价一家餐厅只看厨师的记忆力。真实体验还来自厨房布局、食材质量、点单系统、交接班、卫生规范和出错后的补救。Harness 正是这套围绕模型的工作环境：它组织上下文、工具、会话、循环、插件、进程与事件。

对创始人而言，这个区分非常重要。模型能力可能快速商品化，而产品的长期壁垒往往来自：你如何把复杂工作拆成可追踪对象，如何让人在关键节点介入，如何复用知识，以及如何在客户环境里稳定升级。

Agent 的时间线关心：目标是什么、下一步调用哪个工具、何时停止。Harness 的时间线关心：进程是否启动、session 是否存在、事件是否追加、工具调用有没有返回。企业交付的时间线关心：哪一个任务被授权、哪一次 Run 产生了哪个 ArtifactRevision、谁提出修改、谁最终验收。

这三条线可能同时向前，却不会自动互相推出。例如 Harness 报告 turn completed，只能说明一次执行循环结束；它不能证明产物满足业务标准。反过来，业务负责人接受了一份成果，也不表示底层所有 session、日志和临时资源都已安全清理。

LumiClaw 的关键价值不应是复制另一个 Agent Harness，而是把 Harness 放在 Runtime lane：它可以被替换、升级或停用，而 Task、Run、Artifact、Evidence、Acceptance 和 Knowledge 仍由 Core 掌握。这样才能同时享受执行创新与企业可控性。

假设你让系统为一个客户生成竞品研究。产品先创建 Engagement 和 Task，明确交付标准与可访问的数据源；Runtime Adapter 再选择一个经过批准的 Harness 配置，固定模型、工具、仓库模式和权限；Harness 负责运行 Agent Loop、调用搜索与文件工具、保存 session 事件。

运行结束后，平台不应只展示一段聊天。它要形成可回放的 ArtifactRevision，标记引用和 Evidence，并进入审查。若负责人提出 changes_requested，系统应创建新的尝试，而不是覆盖旧成果；最终 accepted 只改变业务验收状态，不抹掉前面的失败和修改历史。

这条路径解释了为什么 LumiClaw 更像“FDE 交付领域的 Obsidian”：插件可以贡献能力和视图，但用户长期积累的是结构化的工作事实、成果关系和知识，而不是散落的聊天记录。

第一类标准是执行能力：模型与工具是否可替换、上下文如何构造、session 是否持久、是否支持取消与恢复。第二类是工程可靠性：配置是否可重现、事件能否关联到当前请求、崩溃后会不会盲目重试不可逆动作。第三类是企业边界：权限是否真实强制、凭据是否最小暴露、运行结果是否能进入独立验收。

DeepSeek Harness 在插件化、可组合 Agent Loop 和 session 事件方面很有启发；但企业产品还必须补上依赖闭包、配置身份、repo mode、执行证据、Approval 通道、Acceptance 分离和多种部署形态。学习它，不是把它奉为完整答案，而是看清它解决了哪一段问题。