| 栏目 | Harness | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| 层级 | 子知识 | ||||||||
| 描述 | CSC团队方案对比分析 | ||||||||
| status | success | ||||||||
| 时间戳 | 2026-04-11 | ||||||||
| 摘要 | 对比 CSC 冯梦琦团队的 Harness 探索方案与本方案的异同，含三大核心差异、Hook 机制专项分析、CSC方案定位判断 | ||||||||
| 关键词 |
|
||||||||
| 父文档 | Harness - 索引 - 总览 |
原文：https://docs.corp.kuaishou.com/d/home/fcADhKMIO1vZFQ-b4fk8l_Wbd 作者：冯梦琦（CSC 系统研发组） 分析立场：以本方案为底层不动摇，只提取可学习的设计点
CSC 文档引用的一张图值得记录：
Prompt Engineering ⊂ Context Engineering ⊂ Harness Engineering
指令设计 上下文设计 系统工程
措辞优化 信息架构 约束机制
角色设置 策略搜索 反馈回路
格式约束 记忆管理 工作流控制
与本方案的共识：Harness 不是 Prompt，是更外层的「系统工程」——CI/CD 集成、质量管理、可观测性。这和本方案「文件是唯一真相来源 + git 是最后裁判」的理念一致。
| 维度 | 本方案 | CSC 方案 | 差异点 |
|---|---|---|---|
| 驱动方式 | 纯 Skill（Agent 自主读文件推进） | Ralph 循环 + 脚本编排 | CSC 倾向外部脚本控制，本方案 Agent 自驱动 |
| 状态管理 | harness.yaml + feature.csv | progress.md（类 Ralph） | 本方案更结构化（YAML vs 自然语言） |
| 记忆体系 | 三级命名文档 + frontmatter 检索 | 技能库 + 配置类 skill | 本方案更系统化，有明确分层 |
| 任务拆分 | feature.csv（ID/AC/Memory 字段） | plan.md + 子任务拆分 | 本方案任务粒度更细，有 AC 验收机制 |
| 测试闭环 | 单元测试套件（S001-S008 已跑通） | Log-opt Agent + test agent | CSC 有完整 log 驱动测试体系，本方案偏弱 |
| 人工介入 | hitl_level 字段（0/1/2 三档） | Research→Planning→Implementation 三段 HITL | 设计理念一致，实现路径不同 |
| 多 Agent | subAgent 自主调度（已落地） | 分工明确（Research/Plan/Review/Code 四角） | CSC 角色更分明，职责边界更清晰 |
CSC 的设计：
Research Agent 先做 POC/可行性调研，实时探索最新代码信息，不依赖各个层级的记忆文档。
为什么值得学：
- 本方案当前的「plan.md Pattern」直接从 PRD 跳到方案设计，中间缺少「代码现状探索」步骤
- 对于复杂任务，Agent 在没有 Research 阶段的情况下，设计出来的方案容易与现有代码脱节
- CSC 强调「不依赖记忆文档，实时探索」——这正是 Research 的核心价值：不受历史偏见影响
如何集成到本方案：
当前生命周期：
PRD → [节点1 方案讨论] → DEMO → ...
改进后：
PRD → [节点0 Research] → [节点1 方案讨论] → DEMO → ...
↓
实时读代码（不走记忆文档）
产出：research.md（代码现状 + 可行性判断）
↓
注入节点1的 Memory 列（ref 前缀）
新增 Pattern：research.md
- 输入：PRD 摘要 + 目标文件列表
- 工具：read_file / search_file / grep（Research 阶段允许 grep！）
- 输出：
研究 - 细节 - xxx调研.md - 注意：Research 阶段不写 feature.csv，只产出调研文档
CSC 的设计：
Review Agent 做交叉验证：计划完成度、无 bug、设计有无不合理。 模型路由：先 sonnet4.6、后 gpt5.4 / gpt5.3 codex，最后 sonnet 收尾。 「只说不做，直接修还是 Claude」
为什么值得学：
- 本方案当前的 AC 验收是同一个 Agent 自己验证自己——存在「裁判+运动员」问题
- CSC 用不同模型来 Review，避免同一个模型的思维盲点
- 「只说不做」是关键设计：Review Agent 只输出问题列表，不直接修代码
如何集成到本方案：
- 在 feature.csv 加一个字段：
Reviewer（可选，指定 Review 模型） - 高 hitl_level 任务完成后，自动触发 Review subAgent
- Review 的产出写入「日志 - 细节 - D00x-review结论.md」
CSC 的设计：
日志契约驱动的 AI 自测体系：通过日志格式约束来验证代码行为。
为什么值得学：
- 本方案的测试目前只有「单元测试套件」（验证 Harness 体系本身），没有验证业务代码正确性的机制
- Log 驱动测试是轻量的：不需要复杂的 mock，只需要关键行为有日志输出，Agent 检查日志是否符合约定格式
- 对于「是否真正执行了」这类问题，日志契约比静态代码分析更可靠
如何集成到本方案（轻量级版本）：
任务 D00x 完成后，加入一步：
1. 运行代码（如 yarn start）
2. 触发目标操作
3. browser_agent 或 Playwright 脚本抓取控制台日志
4. 检查日志是否包含约定的 key 字符串
5. 通过 → AC 验收通过；不通过 → 触发修复循环
CSC 的设计：
开发：Claude sonnet
Review：sonnet → gpt5.4 → gpt5.3 codex → sonnet 收尾
目的：不同模型 Review，避免同一模型思维盲点
为什么值得学：
- 目前本方案所有环节都用同一个模型
- Review 阶段换模型的成本很低（只是输入 prompt + 产出，不需要工具）
- 「用更便宜的模型做 Research，用更强的模型做 Review」是合理的成本分配
如何集成到本方案：
- 在 feature.csv 新增可选字段：
Model（默认空，空则用当前模型） Model=review触发时，提示用户切换到 o3/gpt4 等做 Review
| CSC 设计 | 原因不采用 |
|---|---|
| Ralph 循环脚本 | 本方案已确认纯 Skill 路线，Bootstrap 脚本复杂度高收益低 |
| progress.md（自然语言进度） | 本方案 harness.yaml + feature.csv 更结构化，可机器读取 |
| 环境初始化 agent | 本方案工作区已就绪，不需要环境初始化这一层 |
| 钩子/中间件探索 | CSC 还在探索阶段，本方案优先验证核心流程 |
| 优先级 | 行动 | 对应设计点 |
|---|---|---|
| P0 | 新增 research.md Pattern |
设计点 1 |
| P1 | 在 feature.csv 加 Review 机制 | 设计点 2 |
| P2 | 在 frontend demo 任务加 Log 契约验证步骤 | 设计点 3 |
| P2 | 探索 Review 阶段多模型路由 | 设计点 4 |
CSC 方案和本方案的底层认知完全一致：Harness 是系统工程，不是 Prompt 技巧。
最大的差异在于执行路径：
- CSC 走「脚本编排 + 多人分工」
- 本方案走「纯 Skill + Agent 自驱动」
两者各有适用场景。CSC 适合团队协作，多人可以分别负责不同 Agent；本方案适合个人高效迭代，单人可以跑完整个生命周期。
最值得借鉴的一句话（CSC 文档 Research Agent 说明）：
「不依赖各个层级的记忆文档，实时探索最新代码信息」
这恰好补了本方案一个盲点：记忆文档是对过去的积累，Research 需要对现在的探索。两者不能互相替代。
经过深度讨论，得出更精准的定位：
CSC 目标架构（空中楼阁）：
Research Agent → Plan Agent → Code Agent × N → Review Agent
↓
Log-opt Agent + Test Agent
↑
这一切依赖什么支撑？
= 状态管理 / 任务拆分 / 记忆检索 / AC 验收 / HITL 控制 / git 裁判
= 本方案已经解决的问题
本方案（地基与支柱）：
feature.csv + 三级命名文档 + frontmatter AC + hitl_level + git
CSC 文档表格中大量「暂无额外需求」「后续规划」「探索中」，不是他们不需要，是还没想清楚怎么做。本方案已经跑完 S001-S008 边界测试，修复 10 个缺陷，成熟度差了至少两个版本。
| 维度 | 本方案 | CSC 方案 |
|---|---|---|
| 实现路线 | 纯 Skill（Prompt 驱动，Agent 自驱动） | PocketFlow 风格（脚本编排 + 多 Agent 分工） |
| 验证周期 | 天级（Prompt 改完即可跑） | 周级（需要写编排脚本） |
| 适用规模 | 个人单兵 | 团队协作 |
| 理论完整度 | 已验证（含缺陷修复记录） | 探索阶段 |
一句话总结：本方案是 CSC 所描述的 Harness 理想架构的「快速验证版本」，两者目标一致，路径不同。
CSC 文档中 hook 仅有一张聊天截图，内容是：
「咱们支持 hooks 了吗？也能直接读 claude code 的 hooks 配置？」 回复：「支持了 今天发版」
即 CSC 关注的是 Claude Code 官方 Hooks 机制，是 codeFlicker 平台层面的能力支持问题，不是设计层面的创新。
类比 git hooks，Claude Code 在 Agent 行为生命周期的特定时机触发外部脚本：
git hooks 触发点： Claude Code Hooks 触发点：
pre-commit PreToolUse （工具调用前）
post-commit PostToolUse （工具调用后）
pre-push Stop （Agent 停止前）
commit-msg Notification （有通知时）
SubagentStop （subAgent 停止前）
配置方式（.claude/settings.json）：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write",
"hooks": [{ "type": "command", "command": "eslint --fix $CLAUDE_TOOL_INPUT_PATH" }]
}
]
}
}| 场景 | 本方案现状 | Hook 能提供什么 |
|---|---|---|
| 写完代码自动 lint | Pattern 里写提醒，Agent 自觉执行 | PostToolUse → 强制跑 lint，100% 触发 |
| 危险命令拦截 | hitl_level 任务级控制 | PreToolUse → 工具层白名单，不经过 LLM |
| 任务结束自动 git commit | HARNESS.md 规则要求 Agent 做 | Stop → 强制兜底，Agent 忘了也能跑 |
| Obsidian 同步 | 手动跑 S008 | PostToolUse → 写文件后自动 sync |
本质差异：
Prompt 规则 → Agent 有时会忘 / 理解偏差 / 被任务内容分心（软约束）
Hook → 100% 触发，不经过 LLM，纯脚本（硬约束）
Hook 对 CSC 的脚本编排路线是必要胶水（各 Agent 之间的信息传递依赖 hook 串联）。
对本方案是可选加固层——本方案通过文件 + Prompt 规则已经实现了大部分 hook 的效果，但 hook 可以把「Agent 自觉」升级为「工具层强制」，提升可靠性。
是否融入本方案：待后续讨论，目前不急，优先跑完 D001-D008 验证核心流程。