内部技术分享 / 2026-06-03
不是调 prompt，是把 AI 当成团队成员，
给它一个完整的工作环境。
agenda.toml
// background Harness 背景
早期：怎么让模型听我的话？
核心技能：写好提示词。
中期：怎么给模型最好的上下文？
核心技能：RAG、上下文压缩。
现在：怎么让 AI 靠谱地工作？
核心技能：软件工程 + AI 协同。
Harness 的本质：不是新技术，是软件工程全流程自动化
// openai-harness-practice Harness 实践
核心洞察
人类只做三件事：设计环境 · 定义意图 · 建立反馈循环。其余全部由 agent 完成。
// se-vs-harness Harness 核心
不是新技术，是成熟实践的重新排列组合
| 传统软件工程 | → | LLM Harness | 实际案例 |
|---|---|---|---|
| 测试框架（pytest） | → | Evaluation Harness | OpenAI：pytest 直接复用，验证 Codex 输出 |
| CI/CD Pipeline | → | Quality Gates | Custom linter 强制架构边界（Types→Config→Repo→Service→UI） |
| 代码审查（PR Review） | → | Agent Review Pattern | Ralph Wiggum Loop：Codex 写 PR → agent review → 迭代直到通过 |
| 类型系统 / Linter | → | Constraints（约束层） | Structured logging、命名规范、文件大小限制，全部自动强制 |
| 可观测性栈（ELK/PromQL） | → | Agent 可观测性 | Codex 直接查 LogQL/PromQL：推理"确保启动在 800ms 内" |
| 技术债务管理 | → | Entropy & GC | 定期 agent 扫描 drift，开 targeted refactoring PR，automerge < 1min review |
| 模块化 / 依赖注入 | → | Three Engineering Primitives | Git worktree 隔离 + OpenSpec 分解 + Supervisor 协调 |
核心洞察：Harness 工程复杂度不在"AI"里，在
约束设计 / 反馈环 / 质量闸门 / 可观测性 / 技术债务管理——全是 SE 的活儿
// what-is-harness Harness 定义
Harness Engineering 是围绕 AI Agent（特别是 Coding Agent）设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。
核心问题：当 AI Agent 拥有了强大的代码生成能力后，如何确保其输出的可靠性、一致性和长期可维护性。
以前：人写代码 → 人跑测试 → 人 Review → 人部署
现在：AI 写代码 → Harness 兜底 → 人 Review → 流水线打包
三大工程原语（综合 OpenAI + Anthropic 实践）
每个 Agent 独立工作空间，冲突结构上不可能发生。git worktree per change
先探索再计划最后编码，给边界 + 验收标准。Explore → Plan → Implement
Spawn（派生）专用子 Agent，Supervisor（督导/包工头）Hook 控制节奏。Subagents + Hooks
Supervisor = 分解任务 → 派 sub-agent 并行 → 用 Hook 拦截关键节点
// feedback-loop Harness 反馈机制
关键原则：反馈环路越短越精准，问题在第一层被拦住成本最低
// implementation · skill Harness 工具层
共 25 个 SKILL，覆盖需求→设计→开发→测试→部署全流程
// implementation · specs Harness 规格层
用Delta 格式记录变更——不重写完整规格，只记 diff。
把 AI 从工具变成团队成员——给它完整工作流和协调机制。
SPEC = 约束 + 协调 + 反馈 — 模糊需求 → AI 可执行的精确规格 → 输出可预期、可验证
// implementation · mcp Harness 集成层
AI 可以直接读生产数据、做 API 测试、执行部署——不需要人来回切换工具
协议层：Model Context Protocol
Anthropic 提出的工具调用标准
🔮 OpenViking
让 AI 记住跨会话的上下文和经验，实现持久化记忆
🗺 GitNexus
代码图谱工具，替代脚本搜索，减少 Token 占用
// implementation · multi-agent Harness 协作层
⚙️ 各个 Agent 工具配置不同模型，各取所长
日常开发
全流程开发
AI Code Review
协作方式：通过 Markdown 文档传递上下文
AI Code Review 已实际运行：资源组模块 → 发现 4 个严重问题 + 3 个高/中问题
代码生成速度 >> 人 Review 速度 → 所以让 AI Review AI
// implementation · code-standards Harness 规范层
AGENTS.md 定义了团队约定，让 AI 知道什么该做、什么不该做。
新建仓库存放 Harness 文档/脚本，业务代码通过 Submodule 引入
// results Harness 效果
需求分析 + 设计 + 开发 + 单测 + API 测试 + 部署预估：12 人天
AI 生成 + Harness 兜底 + 人 Review
预估：4 人天
// implementation · workflow Harness 流程
`/opsx:propose "添加XX功能"` → 输出概要设计文档，归档到 doc/Design/
OpenSpec 生成 task 清单，每个 task 明确边界 + 验收标准
Supervisor 分配任务，Claude Code / OpenCode / Codex 并行开发
Agent 为自己生成的代码编写单元测试并通过；AI Review + 人工审阅并行
Agent 执行部署 + API 测试 + UI 测试（降低 CI 成本）
Human in the Loop — 最终确认后 merge 代码
需求开发流：SD文档 → OpenSpec变更 → 代码实现
BUG修复流：Jira单号 → 复现 → 修复 → 关闭
// gaps Harness 完善度
// lessons-learned Harness 实践
用任务看板组织多个 Agent 并行开发
单一开发需求上，任务拆分反而是负担。Agent 本身就擅长处理模糊任务，不需要人先拆好。
多任务同时在跑，需要频繁切换看：任务跑到哪了？卡死了吗？跑偏了吗？收拾烂摊子的时间，往往比并行节省的时间还多。
用 Tmux 监工 Claude Code 等 Agent
Agent 执行过程中遇到问题，仍需要人介入决策。Tmux 监工变成了"人在旁边等着"，并没有真正释放人的时间。
Openclaw + Tmux 的组合适合个人开发者小规模使用，扩展到团队多人协作时，沟通成本骤增。
工具链极度过剩，选型比开发更重要
试用了 87 个 CodingAgent 工具（WEB 终端、本地工具、任务看板、IM Bot 等），结论：
这些工具本质上都在利用 ClaudeCode、OpenCode 等 CLI 能力——可用可不用，最可靠的还是直接用 CLI。
预期形式：看板管理多个 Agent并行开发，实现团队级自主代码管理，Agent 都能自主运行。
核心教训：工具是为工作流服务的，不要为了用工具而用工具
// limitations Harness 边界
AI 代码生成速度 >> 人 Review 速度。
所以业界有了 AI Review AI。
人的介入点必须前移——
在规格层约束 AI，
而不是在执行层救火
💡 要重新理解"完全无人干预"
完全无人干预不是一个 0/1 的状态。现阶段真正有价值的不是追求 100% 的无人化，而是把人工干预的频率和成本降到足够低——低到一个人可以同时"监护"几十个并行运行的任务，只在少数需要判断的关键节点介入。
这正是 OPC 场景下这套系统的价值所在：不是替代人，而是把一个人的产能放大到原来的几十倍。
// summary Harness 总结