长期编程代理的设计哲学:让 AI ＂忘记＂反而更聪明

6.1 200 功能宣言

演讲展示了一个雄心勃勃的项目：Canopy，一个类似 JIRA 的项目管理应用。

技术栈：

• 前端：React 18 + Vite 6 + Tailwind CSS v4
• 路由：React Router v7
• 状态管理：React Context + useReducer + Dexie
• 数据层：Dexie.js (IndexedDB 封装)
• 拖放：@dnd-kit
• 图表：Recharts
• 搜索：MiniSearch (BM25 排序)

特点：

• 🌐 纯浏览器应用，无服务器端
• 💾 IndexedDB 持久化
• 📱 看板、Sprint、Epic、仪表板
• 🔍 全文搜索
• 📊 燃尽图、速度图

6.2 真实功能实现：日语翻译

演讲中展示了一个真实的功能请求（Issue #36）：将应用翻译成日语。

代理的工作过程：

1. 理解现有代码

"让我理解测试结构...""让我读取 tests.json 的最新内容...""让我理解当前应用结构...   "

1. 拍摄大量截图
   （约 150 张）
• 拍摄当前状态
• 实现翻译功能
• 验证每个页面
• 检查控制台错误

2. 提交代码

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(linegit commit -m "Add Japanese translation feature- Added language switcher in settings- Implemented i18n for all pages- Tested translations across the appCo-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"

1. 结果

• ✅ 功能完整实现
• ✅ 所有测试通过
• ✅ 文档自动更新
• ✅ 单次会话完成（< 1 小时）

6.3 复合效应

时间线：

• 前 5 分钟：环境设置、理解上下文
• 30 分钟：核心功能实现（MVP 花了约 1 小时）
• 1 小时：会话限制（可达 8 小时）
• 数天：200+ 功能的完整应用

关键数据：

• 从 Issue #14（MVP）到 Issue #144（日语翻译）
• 130+ 功能自动实现
• 每个功能平均 < 30 分钟
• 零人工编码

七、设计哲学：避免"AI 生成"审美

项目中有一个特别有趣的部分：系统提示（System Prompt）中包含了详细的设计指南。

7.1 问题：AI Slop 审美

演讲指出，AI 模型倾向于收敛到"安全、通用"的设计选择：

• 居中布局
• 紫色渐变
• 统一圆角
• Inter 字体

这就是用户所说的"AI Slop 审美"。

7.2 解决方案：融合设计身份

要求代理混合多个来源创建独特美学：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line<design_inspiration>  <themes>    配色方案：Monokai, Dracula, Nord, Tokyo Night...    设计运动：包豪斯, 瑞士国际风格, 孟菲斯集团...    品牌语言：Stripe, Linear, Vercel, Notion...  </themes>  <fonts>    展示字体：Clash Display, Space Grotesk...    正文字体：Satoshi, DM Sans...    等宽字体：JetBrains Mono, Fira Code...  </fonts></design_inspiration><specific_design_guidelines>永远不要选择单一主题。通过组合不同来源创建独特美学：1. 配色方案：从一个美学/主题中提取2. 排版：从不同时代或运动中提取3. 布局：应用另一设计流派的原则4. 细节：从意想不到的地方借鉴示例融合："我将结合 Tokyo Night 配色、Kinfolk 编辑排版、瑞士国际网格布局原则和 PlayStation 5 UI 细节。"</specific_design_guidelines>

7.3 动画与微交互

系统提示还强调了使用现代动画：

• CSS transitions（悬停、焦点、激活状态）
• CSS animations（延迟的交错显示）
• Intersection Observer（滚动触发动画）
• Web Animations API（复杂序列）

重点：高影响、低代码的技术，在不增加太多生成时间的情况下大幅提升视觉质量。

八、技术细节深度解析

8.1 为什么使用 XML 而非 Markdown？

在 BUILD_PLAN.md 中，规范使用 XML 标签结构：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line<project_specification>  <project_name>Canopy - Full Featured Project Management Application</project_name>  <overview>    构建一个功能完整的类 JIRA 项目管理应用...  </overview>  <technology_stack>    <frontend_application>      <framework>React 18</framework>      <build_tool>Vite 6</build_tool>      ...    </frontend_application>  </technology_stack></project_specification>

原因：XML 标签提供了结构，模型在读取这种结构时表现更好。

8.2 上下文管理：150 张截图如何不爆内存？

代理在单次会话中拍摄了约 150 张截图。如何处理这么多上下文？

Claude Agent SDK 的内置能力：

• 自动上下文压缩
• 智能摘要
• 只保留必要信息

演讲者强调，SDK 能够自动管理上下文，将其最小化到仅需要的部分。

8.3 会话超时处理

问题：如果 1 小时会话时间到了，但功能还没完成怎么办？

解决方案：在会话结束前强制提交

ounter(lineounter(lineounter(lineounter(lineounter(line# 伪代码if session_time_remaining < 5_minutes:    # 即使工作未完成，也提交当前进度    git.commit("WIP: Partial implementation of feature X")    update_progress_file("Feature X: In progress, need to continue...")

这样下一个会话可以：

1. 看到未完成的提交
2. 读取进度文件
3. 清理并继续工作

九、CloudWatch 日志：窥探代理的思维

演讲中展示了 CloudWatch 日志，揭示了代理的"思维过程"：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line[Session Start]正在初始化环境...后台任务已启动...[Context Loading]让我理解测试结构...读取 tests.json 的末尾以查看最新测试...正在查看之前的提交...[Understanding Current State]让我理解当前应用结构和文件...正在读取 src/components/...正在读取 src/pages/...[Screenshot Analysis]拍摄首页截图...分析：导航栏正常，但缺少语言切换器拍摄设置页面截图...分析：需要添加语言选择下拉菜单[Implementation]正在创建 i18n/ja.json...正在更新 Settings.tsx...正在测试翻译...[Verification]运行端到端测试...✓ 所有测试通过✓ 控制台无错误✓ 视觉检查通过[Commit]提交更改：添加日语翻译功能

这种透明度让人类审查者可以：

• 理解代理的推理过程
• 发现潜在问题
• 学习代理的方法

十、局限性与挑战

演讲者非常诚实地讨论了系统的局限性。

10.1 已知限制

1. 视觉差距

• 模型可能无法看到每个视觉 Bug
• 需要人类判断
• 示例：细微的对齐问题、颜色对比度

2. 浏览器自动化限制

• Playwright/Puppeteer 无法看到原生警告框
• 某些交互难以自动化

3. 不能替代人类审查

• 这不是"fire and forget"（设置后不管）
• 需要在生产前验证

10.2 未解决的问题

演讲者提出了三个开放性问题：

问题 1：单代理 vs. 多代理架构？

当前：1 个初始化代理 + 1 个主编码代理

思考：

• 是否应该有专门的测试代理？
• 是否应该有专门的文档代理？
• 更多代理 = 更好的结果？还是更多协调开销？

问题 2：是否能推广到 Web 应用之外？

当前优化：JSON、TypeScript、React、Node.js

未探索：

• 数据科学工作流
• 移动应用开发
• 嵌入式系统
• 游戏开发

问题 3：未发现的失败模式？

运行时间：几周

担忧：

• 运行几个月会发生什么？
• 技术债务累积？
• 设计问题？
• 新的 reward hacking 方式？

十一、关键学习要点

11.1 模仿真实开发者工作流

核心原则：越像真实开发者工作，代理效果越好。

具体实践：

1. 阅读文档

• Git 提交历史
• 进度文件
• 测试结果

2. 理解当前状态

• 在修改前先理解
• 拍摄截图验证理解

3. 保持环境清洁

• 修复所有测试
• 清除控制台错误
• 为下一次会话留下干净状态

4. 先测试后宣布成功

• 永远不要跳过测试
• 端到端验证
• 截图证据

11.2 标准即控制

重要理念：standards.md 文件是只读的。

示例 standards.md 内容：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line# 编码标准## 架构决策- 使用 React Context 进行全局状态- 每个功能一个文件夹- Dexie 用于所有数据持久化## 代码风格- 使用 Prettier 默认配置- 函数式组件，不用类组件- TypeScript strict 模式## 测试要求- 每个功能必须有端到端测试- 使用 Playwright 进行 UI 测试- 至少 80% 代码覆盖率## 禁止事项- 不要修改或删除现有测试- 不要引入新的依赖而不说明原因- 不要改变核心架构决策

你控制输出：不喜欢某些东西？更新 standards.md。

11.3 规范驱动开发

流程：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line1. 人类编写详细规范（Markdown）   ↓2. 代理生成 features.json   ↓3. 代理逐个实现功能   ↓4. 代理标记测试通过   ↓5. 人类审查并批准

关键成功因素：

• 规范足够详细以指导工作
• 规范足够灵活以允许探索
• 清晰的验收标准

十二、与传统方法的对比

12.1 开发者时间分配变化

洞察：从"写代码"转向"做决策"。

12.2 速度对比

传统方式：

• MVP：2-3 周（1-2 名开发者）
• 每个功能：1-3 天
• 总计（200 功能）：6-12 个月

AI 辅助方式（Canopy 项目）：

• MVP：1 小时（自动化）
• 每个功能：< 30 分钟（自动化）
• 总计（200 功能）：~100 小时 = 约 2 周连续运行

注意：这不包括：

• 需求定义时间
• 人类审查时间
• 修复失败时间
• 设计迭代时间

十三、实践建议

13.1 如何开始

Claude Agent SDK：

• 📦 已发布并可用
• 📚 文档和快速入门可用
• 🔧 可以今天就开始实验

步骤：

1. 阅读博客文章

• Anthropic 发布了详细的研究文章
• 包含所有模式和最佳实践

2. Fork 示例项目

• 使用文档中的快速入门
• 从小处开始

3. 定义你的标准

• 创建 standards.md
• 要具体和规范性

4. 编写详细规范

• XML 结构化格式
• 清晰的验收标准
• 测试场景示例

5. 迭代和学习

• 从一个功能开始
• 观察代理如何工作
• 调整你的方法

13.2 最佳实践检查清单

规范编写：

• [ ] 使用 XML 标签结构化
• [ ] 包含清晰的技术栈定义
• [ ] 提供测试场景示例
• [ ] 定义验收标准
• [ ] 包含设计指南（如果适用）

标准文件：

• [ ] 标记为只读
• [ ] 包含架构决策
• [ ] 定义代码风格
• [ ] 列出禁止事项
• [ ] 设定测试要求

环境设置：

• [ ] 创建 init.sh 用于确定性启动
• [ ] 设置 Git 仓库
• [ ] 配置 CI/CD
• [ ] 设置健康监控

测试策略：

• [ ] 要求端到端测试
• [ ] 禁止修改测试
• [ ] 使用浏览器自动化
• [ ] 截图验证
• [ ] 检查控制台错误

会话管理：

• [ ] 设置合理的时间限制
• [ ] 实施超时提交逻辑
• [ ] 监控会话健康
• [ ] 记录进度

十四、社会影响思考

14.1 开发者的未来角色

演讲开始时，Alex 戴着一顶"thinking cap"（思考帽），象征性地表达：

"我们仍然是思考者，即使代理可以为我们做很多工作。"

不会改变的：

• 创造性思维
• 架构决策
• 产品愿景
• 用户同理心
• 道德判断

会改变的：

• 减少重复性编码
• 减少手动测试
• 减少文档编写
• 减少机械性调试

14.2 对团队的影响

初级开发者：

• 可能影响最大
• 传统上做更多"无聊"的工作
• 需要重新定位价值

中级开发者：

• 从编码转向设计
• 更多时间在架构决策上
• 成为"代理牧羊人"

高级开发者：

• 可能变化最小
• 已经专注于高层决策
• 现在有更好的执行工具

14.3 技能组合演变

新需求的技能：

• 📝 规范写作
• 🏗️ 系统设计
• 🧪 测试策略设计
• 👁️ 代码审查
• 🎯 需求工程

减少需求的技能：

• ⌨️ 快速编码
• 🐛 手动调试
• 📄 文档编写
• 🔁 重复性任务

记住那顶思考帽：在 AI 可以构建越来越多东西的世界里，我们作为人类的价值在于思考——提出正确的问题、做出明智的决策、设定有意义的目标。

附录：资源链接

官方资源：

• 📖 Claude Agent SDK 文档
• 🎥 AWS re:Invent 2025 演讲视频
• 📝 Anthropic 研究博客文章
• 💻 GitHub 仓库: 
  https://github.com/anthropics/riv2025-long-horizon-coding-agent-demo

作者按：本文基于 Anthropic 在 AWS re:Invent 2025 的演讲内容和开源项目整理而成，旨在为中文技术社区提供深度技术洞察。所有代码示例和架构图均基于公开资料重新整理。

致谢：

• Alex 和 Nadine（Anthropic 研究团队）
• AWS Bedrock 团队
• Claude Agent SDK 贡献者
• re:Invent 与会者的功能请求

版权声明：

• 原始项目：Apache 2.0 License
• 演讲内容：© Anthropic PBC 2025
• 本文整理：遵循原始许可证

免责声明： 本文仅用于技术学习和交流目的。AI 编程代理技术仍在快速发展中，实际应用应考虑具体场景、团队能力和伦理影响。

如果你觉得这篇文章有价值，欢迎分享给更多开发者朋友！

有问题或建议？欢迎留言讨论！