来源：Harness engineering: leveraging Codex in an agent-first world 日期：2026-02-28
文章核心理念
OpenAI 的 Harness 团队用 5 个月、0 行手写代码构建了一个百万行级产品，核心哲学是：人类掌舵，Agent 执行。他们发现真正的瓶颈不是 Agent 的编码能力，而是环境的可理解性和反馈回路的完备性。
修正后的分析框架
- lofty-fe-claude-plugin = OpenAI 的 Harness 工程（环境/工具/脚手架）
- Lofty CRM 项目 = 被 Agent 操作的目标项目
- CLAUDE.md = 描述如何开发这个插件本身
当前插件已经做到的（与 Harness 对齐的部分）
| Harness 实践 | 插件对应实现 |
|---|---|
| 渐进式信息披露 | Skill 按需加载机制 — 只在需要时注入 skill 内容，天然实现了”给 Agent 一张地图” |
| 执行计划作为一等工件 | feature_list.json + progress_log.json 栈式进度管理 |
| 设计文档版本化 | docs/{feature}/ 工作目录，understand.md / design.md 随代码一起管理 |
| 人类掌舵 Agent 执行 | /feature-dev 自动调度 + 人工确认关键节点 |
| Git worktree 隔离 | /worktree 命令 支持并行多任务 |
| Agent 使用标准开发工具 | MCP 集成 Playwright、GitLab、Figma |
| Reference 文档指导 Agent | skills/{name}/reference/ 下的模板和自检清单 |
差距 1：目标项目缺少 Agent 可读的知识基础设施
Harness 做法： 在目标仓库中维护 ARCHITECTURE.md、QUALITY_SCORE.md、core-beliefs.md、SECURITY.md 等，Agent 在操作目标项目时能”自主导航”理解项目全貌。
当前插件： /init-workspace 创建的是需求级别的 docs/{feature}/，但不维护项目级别的知识库。Agent 每次进入目标项目时，对项目的整体架构、领域划分、质量状态缺乏结构化认知。
缺什么：
- 没有 skill 或机制在目标项目中生成/维护
ARCHITECTURE.md（领域划分 + 分层依赖图） - 没有质量评分追踪（哪些模块质量高、哪些有技术债）
/prd-understanding和/design产出的是单次需求文档，不会沉淀为目标项目的持久知识
差距 2：实现阶段缺少 Agent 自验证闭环
Harness 做法： Agent 写完代码后，通过 Chrome DevTools MCP 启动应用、做 DOM 快照、截图对比、查日志，形成 “写码 → 运行 → 观察 → 修复” 循环。单次运行 6+ 小时。
当前插件： Playwright MCP 已集成，但在 /implement 和 /ui-dev 的工作流中没有要求 Agent 启动目标应用并验证。流程是”实现 → 人工验证 → commit → 结束会话”。
缺什么：
/ui-dev写完 UI 后没有”启动 dev server → Playwright 截图 → 与 Figma 对比”的验证步骤/implement没有”运行应用 → 检查控制台错误 → 验证功能可用”的自检环节- 没有可观测性集成（Agent 无法查看目标应用的运行日志和错误）
差距 3：Hooks 作为架构执行层远未发挥潜力
Harness 做法： 自定义 linter 在 CI 和 Agent 运行时强制校验依赖方向、命名约定、文件大小等。lint 错误信息本身就是修复指导，直接注入 Agent 上下文。
当前插件： hooks/hooks.json + scripts/ 基础设施已搭好，但：
pre-bash.sh几乎为空post-edit.sh是模板
这些 hooks 本应是插件最强大的武器——在 Agent 每次写代码时实时约束。BEM 命名、Composition API、CSS 变量这些规范目前只”写在 skill 里让 Agent 读”，而不是”Agent 违反时立刻得到带修复建议的错误反馈”。
缺什么：
post-edit.sh没有针对目标项目的实际校验逻辑（Vue 2.7 Composition API 检查、BEM 命名校验等）- lint 错误信息没有设计为”Agent 友好”格式（包含修复指导）
- 没有结构化测试验证目标项目的架构约束
差距 4：没有自动化的熵管理/垃圾回收机制
Harness 做法： 后台 Codex 任务定期扫描偏差 → 更新质量评分 → 自动开重构 PR → 大部分 1 分钟内审完 automerge。
当前插件： /lofty-fe-refractor 存在但是纯手动触发。没有定期、自动化的代码质量维护回路。
缺什么：
- 没有 command/skill 支持”扫描目标项目全局质量并输出报告”作为常态化操作
- 没有”Golden Principles”文档让 Agent 在每次实现时自动遵守
差距 5：Agent-to-Agent 协作回路
Harness 做法： Codex 写代码 → Codex 自己做本地 review → 请求其他 Agent review → 回复反馈 → 迭代直到所有 Agent reviewer 满意（Ralph Wiggum Loop）。人类 review 变为可选。
当前插件： /implement → /code-review → /commit 是线性流程，且 /code-review 需要人工触发。没有”Agent 写完后自动触发 Agent review → 发现问题 → Agent 自修复”的闭环。
缺什么：
/implement完成后没有自动调用/code-review形成回路- 没有 Agent 自审机制（写完代码后对自己的代码做一轮 review）
- 如果 review 发现问题，没有自动回到 implement 修复的路径
优先级建议
按照投入产出比排序：
| 优先级 | 改进 | 原因 |
|---|---|---|
| P0 | 在 /implement 和 /ui-dev 中加入 Playwright 自验证步骤 | 基础设施已有（Playwright MCP），只需在 skill 流程中加验证环节 |
| P0 | 强化 post-edit.sh，把代码规范变成带修复建议的实际校验 | hooks 基础设施已搭好，只差实际逻辑 |
| P1 | /implement 完成后自动触发一轮 self-review 再 commit | 不需要新 skill，只需调整 /implement 流程 |
| P1 | 增加”目标项目知识沉淀”skill，在 /design 完成后更新目标项目的 ARCHITECTURE.md | 让跨需求的架构认知持久化 |
| P2 | 将 /lofty-fe-refractor 改造为可定期自动执行的质量扫描 | 从手动触发升级为常态化 |
| P2 | 设计 Golden Principles 机制 | 区分”建议性规范”和”不可违反的不变量” |
核心观点：当前插件的工作流编排能力已经很强（progress tracking、skill dispatch、worktree 隔离），主要差距在于反馈回路的闭合度——Agent 写完代码后缺少自主验证和自修复的能力，依赖人类作为”最后一道关”。