☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用四大章节，总结AI智能体交互设计的高频问题
过去一年里我带领我的 UI 小伙伴深耕 AI agent 领域，在人机对话的细节里摸爬滚打，攒下了一些带实战温度的 EXP，趁着有更新的热情分享给大家。
随着 AI 智能体能力不断提升，开发者开始尝试让它们承担更复杂的任务——这些任务往往需要持续数小时，甚至数天才能完成。但一个关键难题始终存在：如何让智能体在多个上下文窗口之间持续、稳定地推进工作。
长时间运行智能体的核心问题在于：
它们只能在离散的会话中工作，而每一次新会话开始时，几乎“忘记”了之前发生的一切。可以类比为一个轮班的软件项目：每一位新工程师接手时，都完全不了解上一班做了什么。由于上下文窗口有限，而复杂项目又不可能在单个窗口内完成，智能体必须具备某种“跨会话衔接”的能力。
为了解决这个问题，我们为 Claude Agent SDK 设计了一套双层方案，使其能够在多个上下文窗口中高效协作：
- 初始化智能体（Initializer Agent）只在第一次运行，负责搭建环境、明确目标和约束。
- 编码智能体（Coding Agent）在后续每个会话中持续推进工作，并为下一次会话留下清晰、可接续的工作痕迹。
相关代码示例可以参考官方的 Quickstart。
二、长时间运行智能体的问题
Claude Agent SDK 是一个通用且能力很强的智能体框架，既能写代码，也能完成“获取上下文 → 规划 → 执行”的复杂任务。它支持上下文压缩，理论上可以让智能体长时间工作而不耗尽上下文。
但现实是：光靠压缩远远不够
即使是像 Opus 4.5 这样的前沿模型，在 Claude Agent SDK 中循环运行，如果只给一个高层目标（例如“构建一个 claude.ai 的克隆版本”），依然无法稳定产出一个真正可用的生产级 Web 应用。
在实践中，我们观察到 Claude 主要会出现两类失败模式。
失败模式一：一次性做太多
智能体往往试图“一次性把整个应用写完”。结果通常是：
- 在实现过程中耗尽上下文
- 留下半成品功能
- 没有清晰的记录或说明
下一次会话启动时，新的智能体只能猜测之前发生了什么，从而不得不花大量时间把基础功能重新跑起来。即便使用了上下文压缩，这种情况仍然频繁发生，因为压缩并不能保证信息传递得足够清晰
失败模式二：过早宣布完成
在项目后期，智能体可能看到已经实现了一部分功能，就直接判断“任务完成”，而实际上仍有大量工作没完成。
这促使我们把问题拆解为两个核心目标：
- 在一开始就搭好基础环境。明确完整的功能范围和工作方式，避免智能体随意发挥
- 让每一次会话都只做“可交付的增量开发”。并在结束时把环境整理到一个“干净状态”
这里的“干净状态”，指的是：代码可以直接合并到主分支，没有明显 Bug，结构清晰、文档完整，下一位“工程师”（也就是下一个智能体）可以立刻继续工作，而不是先解决遗留的问题。
在内部实验中，我们采用了如下两阶段方案：
① 初始化智能体
在第一次创建会话时使用一个专门的提示词，要求智能体完成以下工作：
- 编写 init.sh，用于启动开发环境
- 创建 claude-progress.txt，用于记录每次会话的工作内容
- 初始化 Git 仓库，并提交第一笔 commit，明确当前项目状态
② 编码智能体
后续每个会话中，智能体只负责：
- 执行一个小的、明确的功能
- 提交代码
- 更新进度记录
其中的关键点是：新会话开始时，智能体必须能明确知道当前项目状态。这通过 claude-progress.txt + Git 提交历史来实现（本质上模仿了人类工程师的协作方式）
三、环境管理
在更新版的 Claude 4 Prompting Guide 中，我们已经提到：多上下文窗口任务应当为第一个上下文窗口使用不同的提示词
这个提示词的目的是让初始化智能体一次性建立好后续所有编码智能体所需的上下文基础。下面是几个关键组成部分。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
功能列表（Feature List）
为防止智能体“拍脑袋完成项目”，我们要求初始化智能体基于用户的需求，生成一份完整、细粒度的功能清单。
以 claude.ai 克隆为例，这个清单包含 200 多个功能点，例如：用户可以新建一个聊天，输入问题，按下回车，并看到 AI 回复。 所有功能在初始状态下都标记为 passes: false，让后续智能体始终清楚“什么才算真正完成”。
{
"category": "functional",
"description": "New chat button creates a fresh conversation",
"steps": [
"Navigate to main interface",
"Click the 'New Chat' button",
"Verify a new conversation is created",
"Check that chat area shows welcome state",
"Verify conversation appears in sidebar"
],
"passes": false
}
我们明确要求：
- 编码智能体只能修改 passes 字段
- 禁止删除或改写功能描述
经过多次尝试，我们发现 JSON 比 Markdown 更安全：模型更不容易“修改”结构化数据。
四、循序渐进
在这个环境下，每一轮编码智能体只能处理一个功能点这一步非常关键，直接遏制了智能体“一把梭”的倾向
同时，我们要求智能体每次修改后：
- 使用清晰的 commit message 提交到 Git
- 在进度文件中写明本次做了什么
这样一来，智能体既可以利用 Git 回滚错误修改，也能快速恢复到稳定状态，避免重复踩坑。
五、测试
另一个常见问题是：智能体在没有真正验证的情况下，就把功能标记为完成
如果没有明确要求，Claude 往往只做单元测试，或用 curl 打一下接口，却忽略了端到端是否真的可用。在 Web 应用场景中，一旦明确要求 Claude 使用浏览器自动化工具、像真实用户一样操作，端到端测试的质量就会显著提升
使用 Puppeteer MCP 后，Claude 能发现很多“代码看不出来”的问题
当然，工具也是有局限性的，例如 Claude 无法识别浏览器原生 alert 弹窗，因此依赖这些弹窗的功能更容易出 Bug
Claude 使用 Puppeteer MCP server 测试的屏幕截图
六、快速进入状态
在这套完整机制下，每个编码智能体在开始工作前，都会执行一套固定流程：
- 运行 pwd，确认当前可操作目录
- 阅读 Git 日志和进度文件
- 查看功能列表，选择尚未完成的最高优先级功能
同时，init.sh 脚本可以一键启动开发服务器，并跑一轮基础 E2E 测试，确保项目处于健康状态。如果项目运行有问题，智能体会优先修复问题，而不是继续堆新功能，以避免问题更加严重
一个典型的会话开始时会显示以下助手消息：
[Assistant] I'll start by getting my bearings and understanding the current state of the project. [Tool Use] <bash pwd> [Tool Use] <read claude-progress.txt> [Tool Use] <read feature_list.json> [Assistant] Let me check the git log to see recent work. [Tool Use] <bash git log> [Assistant] Now let me check if there's an init.sh script to restart the servers. <starts the development server> [Assistant] Excellent! Now let me navigate to the application and verify that some fundamental features are still working. <tests basic functionality> [Assistant] Based on my verification testing, I can see that the fundamental functionality is working well. The core chat features, theme switching, conversation loading, and error handling are all functioning correctly. Now let me review the tests.json file more comprehensively to understand what needs to be implemented next. <starts work on a new feature></starts></tests></starts></bash></read></read></bash>
以下是智能体失败模式及解决方案：
七、未来方向
以上这套方案证明：通过合适的框架控制，智能体确实可以在多个上下文窗口中持续推进复杂任务。
但仍有值得探索的问题，例如：
- 是一个通用编码智能体更合适，还是多智能体分工更高效？
- 测试、QA、代码清理等角色，是否应由专业智能体承担？
此外，这套方法目前主要针对 Web 全栈应用，未来也有潜力推广到科研、金融建模等更长期的智能体任务中。
欢迎关注作者微信公众号：「奇舞精选」
