文章摘要
文章探讨了如何解决AI代理在长时间任务中因上下文窗口限制导致的记忆中断问题。作者提出了双重解决方案：初始化代理负责首次运行的环境设置，编码代理则在每次会话中逐步推进任务，并留下清晰的工作痕迹供下次会话使用。这一方案旨在帮助代理在多个离散会话中保持工作连续性。
文章总结
标题：长效运行AI智能体的有效控制框架
随着AI智能体能力不断提升，开发者开始让它们承担需要数小时甚至数天才能完成的复杂任务。然而，如何让智能体在多个上下文窗口间保持持续进展仍是一个待解决的问题。
核心挑战在于智能体必须分阶段工作，每个新阶段开始时都没有前序阶段的记忆。这就像由轮班工程师负责的软件项目，每位新工程师都对前一班次的工作一无所知。由于上下文窗口有限，且大多数复杂项目无法在单个窗口内完成，智能体需要一种连接不同编码阶段的方法。
我们为Claude智能体SDK开发了双重解决方案： 1. 初始化智能体：在首次运行时搭建环境 2. 编码智能体：在每个阶段实现渐进式进展，并为下一阶段留下清晰的工作痕迹
长效运行智能体的主要问题表现为： - 智能体倾向于一次性完成过多工作，导致上下文耗尽 - 项目后期，智能体可能误判任务已完成
解决方案包含两个关键部分： 1. 建立包含所有必要功能的初始环境 2. 确保每个智能体阶段结束时环境处于"清洁状态"（无重大缺陷、代码有序且文档完整）
具体实施方法：
- 初始化智能体创建init.sh脚本、进度日志文件claude-progress.txt和初始git提交
- 编码智能体专注于单个功能的渐进式开发
环境管理的关键组件： 1. 功能清单：将用户初始提示扩展为包含200多项功能的详细JSON文件 2. 渐进式进展：要求智能体每次只处理一个功能，并通过git提交和进度文件记录变更 3. 测试验证：明确要求智能体使用浏览器自动化工具进行端到端测试
典型工作流程：
1. 通过pwd确认工作目录
2. 阅读git日志和进度文件了解当前状态
3. 选择最高优先级的未完成功能进行开发
常见问题及解决方案：
| 问题 | 初始化方案 | 编码方案 |
|------|------------|----------|
| 过早宣布完成 | 建立结构化功能清单 | 每次只处理单个功能 |
| 遗留未修复缺陷 | 创建git仓库和进度文件 | 通过基础测试验证环境 |
| 功能验证不充分 | 建立功能清单 | 严格测试后才标记完成 |
| 环境配置耗时 | 编写init.sh脚本 | 通过脚本快速启动 |
未来研究方向包括： - 探索多智能体架构的潜力 - 将框架扩展到其他领域（如科研、金融建模）
这项研究由Anthropic多个团队共同完成，特别感谢代码强化学习和Claude代码团队的贡献。
（注：本文保留了约30%的技术细节，删减了部分重复性说明和团队致谢名单中的次要人员信息，同时确保了核心解决方案和工作流程的完整呈现。）
评论总结
以下是评论内容的总结：
LLM的局限性
- 观点：LLM在初期能快速实现70%的目标，但后续30%需要复杂架构且成本高昂，仍无法保证可靠性。
- 引用：
- "the next 10-20% starts to require things like multi-agent judge setups... running into several hundred dollars per run" (评论2)
- "they sing a siren song of simplicity that will lure you to your doom" (评论2)
开发与测试代理的矛盾
- 观点：独立QA代理可能导致开发循环僵局，不如让开发代理自行处理测试。
- 引用：
- "the more you diverge from the dev agent's approach, the less chance it will get to where you want" (评论6)
- "they just get all out of whack... better to have your dev agent be smart about QA" (评论6)
文件系统权限的争议
- 观点：限制代理的文件操作权限可能无效，因其可能通过脚本绕过限制。
- 引用：
- "the agent can write a script to do whatever it wants" (评论7)
- "reinforces that devs shouldn’t trust the agent with filesystem" (评论7)
项目管理工具的对比
- 观点：现有工具（如plane.io）已能高效管理任务，无需重新发明轮子。
- 引用：
- "they’re attempting to reinvent a project tracker... a few versions behind" (评论5)
- "Slice tickets thin and go wild... Why so difficult?" (评论5)
短期交互 vs 长期代理
- 观点：多数实用场景仅需短对话，长会话可能引发问题。
- 引用：
- "Most value has been 1 to 10 turn chats... ban longer chats?" (评论9)
跨领域应用展望
- 观点：类似Git的版本控制框架可能帮助其他领域管理LLM输出。
- 引用：
- "what will this look like for outputs from other job functions?" (评论10)
其他备注：
- 评论3（"BDSM for LLMs"）和评论4（提及Cucumber测试工具）因缺乏实质性内容未纳入总结。
- 评论8为经验性佐证，未提出独立观点。