https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

Agentic 软件工程方法论：

梳理重点：

Agent 失败模式与解决方案
问题（Problem）	Initializer Agent 行为	Coding Agent 行为
Claude 过早宣布整个项目完成	建立一个功能列表文件：根据输入规格（spec），创建一个结构化的 JSON 文件，列出端到端功能描述清单	在每个会话开始时读取功能列表文件，选择一个功能开始实现
Claude 在存在 bug 或未文档化进展的状态下离开环境	写入一个初始的 git 仓库，并创建进度记录文件	会话开始时阅读进度记录文件和 git 提交日志，并在开发服务器上运行一次基础测试，以捕获任何未记录的 bug；会话结束时写入一次 git 提交和进度更新
Claude 过早将功能标记为已完成	建立功能列表文件	对所有功能进行自验证，只有在经过仔细测试之后，才将功能标记为“通过（passing）”
Claude 需要花时间弄清楚如何运行应用	编写一个能够启动开发服务器的 init.sh 脚本	会话开始时先阅读 init.sh

详细论述：AI编程关键不在模型，而在于运行框架与工程约束设计

一、核心问题认知：为什么需要“方法论”

文章的出发点并不是“AI 不够强”，而是指出一个关键事实：

AI Agent 的能力是离散的，而复杂软件开发是连续的。

上下文窗口的存在，决定了 AI 无法天然具备：

• 长期记忆
• 项目全局状态感知
• 自然的阶段衔接能力

因此，AI 编程的关键不在模型，而在于运行框架与工程约束设计。

---

二、基于 AI 的软件开发整体方案（总体架构）

文章提出了一种明确的工程化方案：

用“人类工程师的工作方式”，反向约束 AI Agent 的行为

其核心是一个 长期运行的 Agent 运行框架，由两类 Agent 协同完成：

1️⃣ Initializer Agent（初始化阶段）

职责不是写功能，而是建立工程秩序：

• 定义“什么叫完成”
• 定义“当前进度是什么”
• 定义“后续 Agent 如何接手工作”

2️⃣ Coding Agent（持续迭代阶段）

职责不是“尽快写完”，而是：

• 每次只推进一个明确的、可验证的增量
• 为下一次会话留下可理解、可继承的工件

👉 本质上，这是把 AI 从“即兴写代码的人”，变成“遵守工程流程的开发者”。

---

三、使用 AI 编程工具的标准开发步骤（可复现流程）

第一步：初始化工程环境（一次性）

由 Initializer Agent 完成：

1. 生成完整功能列表（Feature List）
   • 将用户的高层需求，拆解为大量端到端功能
   • 所有功能初始状态设为 未完成
   • 明确“完成”的判定标准
2. 建立工程启动工件
   • init.sh：明确“如何运行项目”
   • claude-progress.txt：记录历史进展
   • 初始 git commit：冻结起点状态

📌 这一阶段的目标不是“写代码”，而是消除不确定性。

---

第二步：增量式功能开发（核心循环）

由 Coding Agent 在每一个上下文窗口中重复执行：

1. 进入状态（Get Bearings）
   • 阅读进度文件
   • 查看 git 提交历史
   • 运行 init.sh
   • 验证当前系统是否仍然可用
2. 选择一个、且仅一个功能
   • 从功能列表中选择一个未完成项
   • 避免 one-shot 心态
3. 实现 → 测试 → 自验证
   • 不仅写代码
   • 必须进行端到端测试（如浏览器自动化）
   • 确认“真的可用”，而不是“看起来对”
4. 留下可继承的工件
   • git commit（清晰描述）
   • 更新进度文件
   • 更新功能状态（passes）

📌 每一次会话都必须 以“可交接状态”结束。

---

四、关键操作层面的有效方法（文章反复验证有效）

1️⃣ 用“结构化工件”替代上下文记忆

• 用文件（JSON / 日志 / git）代替模型记忆
• 工件是 Agent 之间唯一可靠的“共享语言”

👉 AI 不记得没关系，工程状态记得就够了

---

2️⃣ 强制增量，防止 one-shot 失败

• 明确规定：一次只做一件事
• 功能列表作为“进度锚点”，防止提前宣布完成

👉 这是对 AI 最重要的一条工程约束

---

3️⃣ 把“测试”从可选项变为强制步骤

• 不允许“逻辑上看起来对”
• 必须端到端验证
• 浏览器自动化 ≈ 人类用户行为

👉 AI 最大的风险不是写错代码，而是误判完成状态

---

4️⃣ 利用 git 作为“状态回滚与自救机制”

• AI 也会犯错
• 但只要每一步可回滚，错误就不会扩散

👉 git 在这里不是版本管理工具，而是 Agent 的安全绳

---

五、AI 编程的软件工程方法论（抽象总结）

可以将本文的方法论概括为以下几条原则：

🧠 原则一：不要指望 AI 具备长期一致性，要为它设计一致性

一致性来自：

• 结构化文件
• 明确流程
• 可验证状态

---

🧱 原则二：AI 编程必须“工程先于代码”

先解决：

• 状态如何交接
• 进度如何判断
• 失败如何恢复

再解决：

• 代码怎么写

---

🔁 原则三：把 AI 当作“可轮班的工程师”

• 每一轮都可能是“新 Agent”
• 因此必须：
  • 有交接文档
  • 有明确任务
  • 有完成定义

---

📏 原则四：完成 ≠ 写完代码，而是通过验证

在 AI 编程中：

• 未验证的功能 = 未完成
• 验证必须是用户视角、端到端的

---

六、总结

使用强大的 AI 编程工具，并不意味着让 AI 自由发挥，而是通过工程化的运行框架、严格的增量流程和可继承的工件体系，把 AI 约束为一个可以长期、稳定、可交接地参与软件开发的工程角色。

---

Agentic软件工程方法论和项目管理思考：

一、关于现阶段如何更好地利用 AI 进行系统性开发

这篇文章最重要的启示是：

AI 已经具备“写代码”的能力，但还不具备“自然完成系统工程”的能力。

因此，现阶段要想真正把 AI 用在系统性开发中，关键不是“多给提示”，而是改变我们使用 AI 的方式。

首先，不要把 AI 当作一个一次性完成任务的黑箱。复杂系统无法在单个上下文窗口内完成，而 AI 的工作本质是离散的。这意味着，如果仍然采用“想到什么就问一句、生成一段代码就结束”的即兴式使用方式，AI 很容易在中途丢失上下文、重复造轮子，甚至在系统尚未完整时误判任务已经完成。

更合理的方式，是把 AI 视为一个会不断轮换的工程执行单元。每一次会话，都是一个“新的工程师”上岗。既然如此，就必须像对待人类工程师一样，为它提供明确的任务边界、可交接的状态描述，以及清晰的完成判定标准。文章中通过工件、进度文件和功能列表来实现这一点，本质上是在为 AI 构建一个可持续工作的工程环境。

换句话说，系统性开发不是靠 AI 的“聪明程度”，而是靠运行框架为它提供秩序。

---

二、关于 AI 编程的软件工程方法论思考

从软件工程角度看，这篇文章实际上在强调一个非常传统、但在 AI 编程场景中被重新证明的重要原则：

工程秩序优先于代码产出。

文章提出的做法，本质上是在用软件工程的经典方法约束 AI 的行为。功能列表相当于需求规格说明，工件相当于设计与实现的交付物，git 提交和测试相当于质量控制与变更管理。这些在传统工程中由人类完成的工作，被显式地前移并制度化，让 AI 在其中扮演一个受约束的执行者，而不是自由发挥的创造者。

一个非常关键的方法论转变在于：

“完成”不再等同于“代码写完”，而必须等同于“经过验证”。

AI 极易在逻辑上自洽却实际上不可用的状态下宣称完成任务，因此，端到端测试从“可选项”变成了“完成定义”的一部分。这一点对 AI 编程尤为重要。

此外，增量式推进的思想在 AI 场景下显得格外关键。人类工程师尚且会因为一次性做太多而引入复杂 bug，更不用说上下文受限的 AI。通过强制“一次只做一件事”，实际上是在用流程抵消模型的局限性。这种方法并不是为了限制 AI，而是为了让它在长期任务中保持稳定和可控。

从方法论角度看，这篇文章传达的核心思想是：

AI 编程不是降低工程标准，而是需要更严格、更显式的工程约束。

---

三、关于 AI 编程背景下的项目管理思考

在项目管理层面，这篇文章给出的启示同样非常清晰：

AI 并没有消除管理成本，而是改变了管理对象。

传统项目管理中，管理的重点是人：沟通、协作、责任划分。而在 AI 编程场景下，管理的重点转向了状态、流程和交接。因为 AI 本身并不会“记得”项目历史，也不会对长期目标负责，所有连续性都必须由项目结构来保证。

文章中的做法，本质上是把项目管理中的“交接文档”“进度汇报”“代码审查”前置并自动化。进度文件、功能列表和 git 历史，承担了原本由项目经理和团队会议完成的信息同步职能。这样一来，即使 Agent 不断更换，项目仍然可以持续推进。

此外，这篇文章也隐含了一种重要的管理观念：

在 AI 编程中，最重要的不是让 AI 尽可能多地工作，而是让它在任何时刻都处于“可接管状态”。

这与传统项目管理中的风险控制高度一致——任何阶段都必须允许人类介入、回滚或调整方向。

最后，从管理人的角度看，AI 编程并不是“让人退出开发”，而是把人的角色从编码执行者转变为运行框架与流程的设计者。人类的价值不再主要体现在写多少代码，而在于能否设计出一个让 AI 长期稳定发挥能力的系统环境。

---

总结性的思考

综合来看，这篇文章并不是在讲“如何让 AI 写更多代码”，而是在讲：

如何把 AI 纳入到严肃的软件工程体系中，而不是让工程迁就 AI 的局限。

在现阶段，真正高效的 AI 编程并不来自更激进的自动化，而来自更保守、更工程化的约束。只有当 AI 被放入一个清晰的运行框架、遵循明确的增量流程、并接受严格的验证标准时，它才能成为系统性开发中的可靠力量。