内部技术分享 / 2026-04-19
不是调 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 定义
以前：人写代码 → 人跑测试 → 人 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 工具层
SKILL 把运维经验封装成 AI 可调用的工具。
// implementation · openspec Harness 规格层
OpenSpec 的核心创新是不重写完整规格，只记录变更的 diff。
一句话：把"模糊需求"变成"AI 能执行的精确规格"，从而让 AI 的输出可预期、可验证
// implementation · mcp Harness 集成层
AI 可以直接读生产数据、做 API 测试、执行部署——不需要人来回切换工具
协议层：Model Context Protocol
Anthropic 提出的工具调用标准
// implementation · multi-agent Harness 协作层
MiniMax 模型
Oh My ClaudeCode
20+ 专项 Agent
Qwen 模型
50+ SKILL
项目定制能力
GPT-5.4 模型
SuperPower 技能
全流程覆盖
AI Code Review 已实际运行：资源组模块 → 发现 4 个严重问题 + 3 个高/中问题
代码生成速度 >> 人 Review 速度 → 所以让 AI Review AI
// implementation · code-standards Harness 规范层
AGENTS.md 定义了团队约定，让 AI 知道什么该做、什么不该做。
// 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 代码
// gaps Harness 完善度
// lessons-learned Harness 实践
用任务的方式组织 Agent
单一开发需求上，Vibekanban 的任务拆分反而是负担。Agent 本身就擅长处理模糊任务，不需要人先拆好。
多个 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，
而不是在执行层救火
// summary Harness 总结