Initializer + Coding Agent

Q: 「Initializer + Coding Agent」要解决的关键问题是什么？

初始化 Agent 搭环境、编码 Agent 增量推进，双角色 Harness 设计 让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。 写下一个问题：试完这个方法后，你能用什么证据回答它？

本页解决的问题

先给结论

「Initializer + Coding Agent」要解决的关键问题是什么？

初始化 Agent 搭环境、编码 Agent 增量推进，双角色 Harness 设计

判断标准

让这个结论先证明自己值得留下。把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。

下一步

写下一个问题：试完这个方法后，你能用什么证据回答它？

常见误区

结论听起来很完整，却没有检查最关键的假设。

双角色解决方案

两个 Agent，明确分工

只跑第一轮

Initializer Agent

负责从零到有：搭环境、定计划、做第一次提交

创建 init.sh 脚本搭建开发环境
写 claude-progress.txt 进度文件
把用户的高级提示展开成详细的功能清单（JSON 格式）
做第一次 git commit，确保仓库状态干净

每轮都跑

Coding Agent

负责从有到多：逐个功能实现，持续推进

读 progress 文件，了解当前状态
一次只做一个功能
完成后更新 progress 文件
git commit 并写清楚做了什么

功能清单的设计

一种验证有效的做法是用 JSON 格式来记录功能清单，Markdown 不适合这个用途。原因是：模型更不容易错误修改结构化的 JSON，而 Markdown 容易被模型顺手重写。

// claude-progress.txt 中的功能清单
{
  "features": [
    {
      "category": "authentication",
      "description": "Email/password login with session management",
      "steps": [
        "Create login form component",
        "Implement auth API endpoint",
        "Add session cookie handling",
        "Write end-to-end test"
      ],
      "passes": false
    },
    {
      "category": "chat",
      "description": "Real-time streaming chat with Claude API",
      "steps": ["..."],
      "passes": false
    }
  ]
}
  

Prompt 中使用强措辞：明确告诉 Agent「不允许删除或修改已有的测试内容」。否则 Agent 会为了让测试通过而降低测试标准。

增量进度：一次只做一个功能

为什么"一次一个"是关键

1 每次完成一个功能后，代码处于可合并状态：没有半成品、没有语法错误
2 Git commit 提供回滚点：如果下一轮搞坏了什么，可以回到上一个干净状态
3 Progress 文件提供上下文：新 Agent 不用猜做到哪了，直接读文件就知道
4 上下文窗口不会溢出：每轮只需关注一个功能的上下文，不会积累到爆

测试验证

Agent 容易以为做完了却没有端到端验证。它说「实现了登录功能」，但实际上按钮根本点不动。解决方案：

明确要求 Agent 用浏览器自动化做端到端测试。
要真正打开浏览器、点击按钮、验证结果，光有单元测试还不够。让 Agent 用 Puppeteer / Playwright 写 E2E 测试，作为功能是否真正"passes"的判定标准。

最终效果

200+ 功能的 claude.ai 克隆成功构建

通过 Initializer + Coding Agent 的双角色方案，成功让 Agent 自主构建了一个包含 200+ 功能的完整 Web 应用。每个功能都有对应的 E2E 测试，代码始终保持可合并状态。

好的交接机制 = 好的长运行 Agent。进度文件、功能清单、增量提交，这些是让 Agent 能持续推进的最基本保障，一点也不花哨。

「双角色解决方案」如何改变一次回答

「一种验证有效的做法是用 JSON 格式来记录功能清单，Markdown 不适合这个用途。原因是：模型更不容易错误修改结构化的 JSON，而 Markdown 容易被模型顺手重写」说明，模型处理的不是我们眼中的“字数”，而是一段段 Token。Token 的切分方式会影响输入长度、上下文能放下多少内容，以及一次请求要花多少计算。

长度、信息量和上下文不是一回事

当「Agent 容易以为做完了却没有端到端验证。它说「实现了登录功能」，但实际上按钮根本点不动。解决方案」变长时，先要分清三件事：文字被切成多少 Token、哪些内容真正参与当前判断、以及旧内容是否已经超出上下文窗口。删掉重复说明通常比单纯把窗口开得更大更有效。

写 claude-progress.txt 进度文件
把用户的高级提示展开成详细的功能清单（JSON 格式）
做第一次 git commit，确保仓库状态干净

先保留会改变判断的内容

可以用「Agent 容易以为做完了却没有端到端验证。它说「实现了登录功能」，但实际上按钮根本点不动。解决方案」做一次对照：保留同样的问题，分别删掉重复背景、压缩格式和移除无关历史，比较答案质量、延迟与 Token 数量。

从「双角色解决方案」走到「功能清单的设计」

「双角色解决方案」先把问题落在「两个 Agent，明确分工只跑第一轮 Initializer Agent 负责从零到有：搭环境、定计划、做第一次提交创建 init.sh 脚本搭建开发环境写 claude-progress.txt 进度文件把用户的高级提示展开成详细的功能清单（JSON 格式）做第一次 git commit，确保仓库状态干净每轮都跑 Coding Agent 负责从有到多：逐个功能实现，持续推进读 progress 文件…」上；到了「功能清单的设计」，讨论继续推进到「一种验证有效的做法是用 JSON 格式来记录功能清单，Markdown 不适合这个用途。原因是：模型更不容易错误修改结构化的 JSON，而 Markdown 容易被模型顺手重写」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。

把这条判断带到下一个场景

处理长文本时，先保留会改变结论的内容，再决定如何压缩格式和历史；上下文更长只有在新增信息真正有用时才值得付出代价。

「双角色解决方案」：两个 Agent，明确分工只跑第一轮 Initializer Agent 负责从零到有：搭环境、定计划、做第一次提交创建 init.sh 脚本搭建开发环境写 claude-progress.txt 进度文件把用户的高级提示展开成详细的功能清单（JSON 格式）做第一次 git commit，确保仓库状态干净每轮都跑 Coding Agent 负责从有到多：逐个功能实现，持续推进读 progress 文件…
「功能清单的设计」：一种验证有效的做法是用 JSON 格式来记录功能清单，Markdown 不适合这个用途。原因是：模型更不容易错误修改结构化的 JSON，而 Markdown 容易被模型顺手重写
「最后的要点」：2 Git commit 提供回滚点：如果下一轮搞坏了什么，可以回到上一个干净状态

最后的「最后的要点」把讨论落到「2 Git commit 提供回滚点：如果下一轮搞坏了什么，可以回到上一个干净状态」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。

标记为已学完 阅读进度会自动记录

文章讨论

读到这里，留下一个判断。

把刚想明白的地方、还没想通的问题，留给下一位一起学习的人。

↗

正在讨论 Initializer + Coding Agent 可靠 Agent 的工程模式

3条讨论文章讨论 · 与共学社区同步

在共学社区查看

Asha Morgan内容编辑2026年8月20日

观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。

文章讨论7 有帮助

Lin Harper独立开发者2026年8月18日

观点观点

读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助

Kiki Moore产品运营2026年8月15日

问题问题

如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。

文章讨论4 有帮助