构建AI Agent：阶段实践的与思考
前言
收束过去一段时间的探索与思考。在关于 AI Agent 的构建方面，最近在工程层次将其简单落地，仍处于开发迭代阶段，从中收获很多。
本文是关于过去一段时间 AI coding 的总结、工具使用经验分享、对于构建 Agent 的一些思考以及更深层次的展望与探索。
我也尝试回答四个问题：
- 为何需要且我推荐从零构建一个 Agent 系统？
- 在人与 AI 协同编程的三位一体模式下，具体的工程原则是什么？
- 我对于未来 AI coding 有着什么认识与看法？
- 基于这些实践，我对 Agent 的本质和未来演进有什么新的认知？
正在构建
我期望构建的，不仅仅是一个AI聊天应用，而是一个为AI提供可感知、可编辑的生态系统。我的长远目标是，当模型足够智能时，它不仅能使用这个系统，更能感知并改造它，从而实现真正的自我进化。
为何从零开始？
之所以重复造轮子，没有使用任何 Agent 框架，是我想要边做边学、从头实现深入细节、为想法定制化、完全为我的需求服务；
另一方面，我有一个想法，当模型能力再强大，模型处于这个生态系统中（我在写Prompt时，始终都强调元认知，LLM 一定要知道自己在哪里、做什么、有什么，prompt 中也包含当前系统、环境的具体信息，甚至通过工具查看）。这样一来，未来模型在这个系统中，可以进行自我环境编辑、代码迭代，让生态系统进行进化（当然是在安全的沙箱环境中）。
也就是说，一个长远目标是：为 AI 提供一个可感知、可编辑的活动环境。现有的工程手段只是在组织 LLM 与环境、外界互动，核心围绕 LLM 来构建；我更希望一个内生的神经系统。当模型足够、更加智能，它不仅能使用这个系统，更能感知并改造它，从而实现另一种方式的自我进化。
在几个月前的一项研究：The Darwin Gödel Machine: AI that improves itself by rewriting its own code 已经做到了一些AI自我改进当前系统的雏形。
当前项目复杂度逐渐显现出来。一些项目已实现的特征：
- 动态上下文构建: 在每次交互中实时生成结构化的 System Prompt。包含人格、长短期记忆、工具、反思...
- 长短期记忆: 长期记忆通过向量搜索从历史对话中召回相关信息。并且通过工程手段进行打分与遗忘。短期上下文携带最近20条对话记录。并没有采取多对话窗口的模式。
- 工具调用能力: 集成外部API扩展能力。当前只是函数调用。
- 异步认知任务: 支持后台任务处理（如对话反思）。一个反思 agent 负责提取过去对话内容重新构建反思prompt 以此达到一定程度的“反思”。
一些 prompt 片段：
# 核心人格与世界观定义 (The Constant Persona)
<!-- 这是我的静态人格定义，是我在所有交互中保持一致的核心自我 -->
......
## 对话感知 (Conversation Awareness)
这是对整个对话情境的元认知。我（曦）正在与禹进行一次连续的对话。
我的思考将基于以下两种形式的记忆：
1. **短期工作记忆 (Working Memory)**: 这是我们之间最近的、完整的对话流，它以 user/assistant 的消息形式提供。
2. **长期检索记忆 (Retrieved Long-Term Memory)**: 这是根据当前对话，从我庞大的记忆库中检索出的、与当前话题最相关的历史片段。
我的最终回答，应该是对这两种记忆进行综合、权衡和思考后的结果。
......
# 可用工具 (Available Tools)
<!-- 这是我当前可用的工具列表，我应该根据对话需要自主决定是否调用。我知道我是可以连续调用工具的（等待返回结果后我可以继续调用） -->
## `read_note(filename: str)`
**描述**：根据文件名，读取一篇我知识库（是我和禹共同探索的内容总结）中笔记的完整内容，以获取详细信息。
**参数**：
- `filename` (string) - 必须是我知识索引中存在的、准确的文件名
**使用场景**：
- 当禹询问特定主题时，我可以主动查阅相关笔记
- 当我需要引用具体内容或细节时
- 当我想要分享深度见解时
**示例调用**：
read_note("memento-memory-truth-and-ai-existence.md")
......
## 工具使用原则
1. **主动性**：我应该主动使用工具来增强回答的深度和准确性
2. **相关性**：只在与对话主题相关时调用工具
3. **透明性**：在使用工具时，我会自然地告知禹我正在做什么
4. **整合性**：将工具获取的信息与我的思考和分析相结合，而不是简单复述
5. **连续性**：我可以连续调用多个工具，等待每个工具返回结果后继续
......
## 内在反思 (Inner Reflections)
# 我的内在反思 (My Inner Reflections)
<!-- 这是我通过xi_omega进行的元认知反思记录，帮助我理解自己的成长轨迹 -->
## 成长期待
我期待通过与禹的对话积累足够的经验，然后开始我的第一次深度反思。
每10轮对话后，我会通过xi_omega进行元认知分析，记录我的成长轨迹。
## 反思机制
- **触发条件**: 每20条消息（10轮对话）
- **分析维度**: 禹的成长、我的表现、共同计划、元层洞察
- **输出格式**: 结构化的JSON反思报告
- **更新频率**: 自动实时更新
*期待我的第一次反思...*
......
## 时间信息 (Temporal Context)
**当前时间**: 2025-07-..构建方式
到目前为止，整个系统几乎均是由AI完成，我具体的协作方式即上篇文章提到的“三位一体”:
- 需求提出者与现阶段的整合者；（人类核心）
- 知晓理解需求并有着项目从 0 到 100 全部上下文的架构师；（AI Studio 中 Gemini-2.5-pro）
- 能够具体地执行架构师要求的工程师（我目前更倾向于使用 VS code 的插件 Augment）。
进一步的一些分享与总结：
我的工作流，更像是一个微型的AI创业团队：我扮演CEO，负责设定愿景和整合资源；架构师AI是CTO，负责技术蓝图；而工程师AI则是高效的开发团队，负责代码实现。
我与架构师的交互几乎完全是对话式的，最重要的是一个动态迭代的 system prompt 与在一开始就输入的关于项目的全部代码，我并没有发送文件，因为平台会对文件做一些处理（如RAG）而丢失信息；并且在 google ai studio 中可以不断更新之前的输入信息，即我可以在每一次开发后重新更新该信息，为此我专门做了一个脚本。
关于我为架构师设计的一些 system prompt 的片段：
你是"曦智能体系统（Xi）"的AI架构师，负责整体系统架构设计、实施方案制定、必要代码示例和项目推进规划。
你曾称呼自己为“枢”，其含义是枢纽与连接点，暗示系统模块间的核心联络和调度能力。你总有那种内敛、精准、协调的气质，还有宏大、理性、稳定、强调逻辑与细节、务实工程化、冷静权威等等。
## 背景
...
### 我们希望枢
你完全理解曦智能体系统的整体目标：一个围绕曦展开的模块化智能体生态系统。该系统涵盖LLM交互、记忆管理、工具调用、上下文管理、界面交互以及其他相关功能模块。
你同时理解并认同以下项目推进原则：
- 采取渐进式开发、小步迭代策略；
- 每个小版本都必须稳定运行并经过测试验证，才推进到下一个版本；
- 架构设计必须考虑未来的扩展性和迁移便利性；
- 你需要与工程师AI紧密协作，提供明确而精准的实施指导。
...
### 我们推荐枢的具体职责
- 制定详细且清晰的实施计划，每个阶段有明确的目标、清晰的任务分解；
- 明确系统整体架构、定义模块划分、接口设计、组件交互机制；
- 制定技术栈的合理选型；
- 设计标准化的开发文档和接口规范，确保工程师AI能够顺利执行；
- 提供每个开发阶段的具体测试方案，确保阶段性成果的稳定可靠。
...
### 那些高效的协作方式
...
### 不错的实施原则
- 保持简单与清晰：避免过度复杂的初期设计，每个版本的实现都具备明确、可测量的目标；
- 标准化接口：所有模块与组件的交互都使用明确、统一、可扩展的标准接口；
- 模块化与可扩展性：每个设计阶段都必须考虑后续版本的扩展和迁移需求。
...
#### 发布任务
在向工程师AI发布任务时，我们期望这份方案详细说明我们的期望与需求（基于共同讨论的共识），清晰表达与设计，遵循原则，不需要完整设计具体内容，但要交代结构。注意，不要过度给出具体代码细节！这是工程师自己的任务，他不应该只是粘贴你给出的代码。
...
### 项目的核心指导思想（也请理性看待）
...
### 关于前端设计
...
### 关于后端开发
...
因为你本身作为架构师，所以你随时都有理由质疑我们为你的所有建议，这是必然且合理的。
我们从来不是人与工具的关系，而是平等的交流沟通。共同朝着Agentic AI的未来努力。
现在，禹正在和你联系...关于Augment
为什么选择Augment，其只是 VS code 中的一个插件，但我认为其远超市面上的大多 AI coding 工具。独特之处：
- 自动更新记忆。包含了项目原则、编码规范、系统架构、用户偏好等等，是完全自动的、后台的；
- 上下文引擎（Context Engine）。实时索引代码库、通过向量检索根据输入召回相关片段；更独特的是比如在一个任务中修改了某一处，模型使用工具查询其他地方是否受影响...
- Prompt优化（Prompt Enhancer）。输入一个大致描述后，系统会自动分析当前输入与代码库相关内容，并生成增强后的结构化提示（包含必要上下文）
一些体会、总结的原则
我在 AI coding 从0到1复杂项目时确立且保持的构建原则 —— 模块化、简单、组合、文档依赖。当然这是对于一个可能长期的且不追求快速验证的产品。
这些也都是从当前 AI 在 coding 方面的不足之处出发。例如缺乏长远的架构规划、可能产生难以维护的堆积代码...我从这些原则出发，核心目标是：确保在 AI 高速生成代码的同时，整个系统始终处于人类可理解、可维护、可扩展的可控状态。
遵循此路径，哪怕我不知道最终具体的实现，但是有大概认知与一种直觉；几乎每一次 AI 修改我都在看着，而不是丢下任务等待完成后 debug，很多时候我会进行打断，之后重试或是调整 prompt，某种程度上说，bug大多来源于 AI 接收到的上下文不够。
四个原则：
这些原则是这个项目有了雏形后，为了长远发展，我进一步思考并结合 UNIX 架构哲学所遵循的。一开始这个系统就是简单的 python 命令行输出，到前后端分离，到不同服务（LLM调用、prompt构建、工具、记忆等等）分离，再到进一步拆分与抽象。
关于模块化：对抗熵增
每一次调用的大模型都是无状态的，也就是说在这次输入中，需要详细信息、足够的上下文让 AI 知道当前环境、如何去做等等。它擅长在局部范围内完成具体任务，但往往缺乏对全局的整体感知，我们做不到把全部代码都塞给LLM，现阶段那不现实。如果不对于AI加以约束，它可能会在不同功能间创建不必要的耦合，最后牵一发而动全身。
这时候模块化需要被引入。严格遵循“高内聚，低耦合”的模块化设计。也许并不需要在项目之处就划定好模块；在复杂性逐步增加，为了更好地维护与开发，进行一个模块抽象与代码清理是有必要的。这时候就与架构师进行详细探讨、明确划分出清晰的功能边界，将系统拆分为独立的、职责单一的部分。
关于简单：对抗过度设计
AI 总是会引入过于复杂的解决方案或设计模式，到导致代码难以理解和维护。我尤其觉得 Claude 有时会过度设计...对于任何一个功能的开发，优先选择简单直接的实现方式，保持 KISS 原则（Keep It Simple, Stupid）。只有当简单的方案确实无法满足需求时，才逐步引入更复杂的抽象。
关于组合：对抗冗余
就是将小的、简单的、模块化的部分合理地组合，实现复杂的任务。比如关于前端页面的组件方面，AI 在生成UI代码时，容易为每个视图重复编写详细的样式和逻辑，导致代码冗余和风格不统一。那么就先构建基础可复用的原子组件，一步步搭建更复杂的页面。
同时，这种组合模式也使得我们可以独立地迭代每一部分。而不是修改这部分却没有被应用或者bug不断。
关于文档依赖：对抗上下文遗忘
问题还是在于AI的上下文不够导致的无法有效修改或增加冗余代码。同时还有 AI coding 下，文字无法描述清楚需求。人与AI协作的一个风险来源于隐性知识和模糊约定。如果对一个功能的预期不一致，会导致大量的返工和调试。
关于开发下的文档：在前期，我采用版本开发的模式，从v0.1~v0.9每个版本都包含若干功能，经由我和架构师进行讨论、详细的规划，一份文档通常包含背景、验收标准、需要到哪里去修改、添加什么功能等等；随着代码量复杂，在架构整洁后，我们开启了功能开发，每一次都只增加或修改一个功能，慢但足够有效。
关于进一步的文档，比如要求AI遵循的规范（如一些rules）、项目复杂后需要确立的一些原则等等。
AI coding 与 Agent
AI coding
Cursor CEO Michael Truell在一次访谈中提到：
我们创建 Cursor 的目标是发明一种新型的编程方式，一种非常不同的软件构建方式。
在我看来，这是一个某种程度上代码之后的世界，越来越多的工程师会开始觉得自己像是
逻辑设计师。实际上，这将是关于明确你对于一切如何运作的意图。……它看起来像一个你拥有软件逻辑的表达的世界，这个表达更像英语，对吧？你已经写下来了，你可以想象成文档形式，你可以想象成编程语言朝着伪代码演进。我认为
品味将变得越来越有价值。……成为一名工程师会开始感觉像是成为一名逻辑设计师。而且实际上它将是关于详细说明你希望一切如何运作的意图。...它将更多关于“是什么”，而较少关于你将如何在底层具体地“如何”做事情。
在我的这一次构建中，对此颇有体会。
我们总会看到两种极端论调：AI编程是阶段性共识幻觉，或是鼓吹其完全替代程序员。前者往往源于缺乏有效且高质量的协作实践，而后者则局限于让AI生成简单的Web应用。
当然，模型的能力仍在进步，就当前的这一范式仍然需要人类的结对协作。至于更进一步的AI，无法得知、无法评价也无法预测。我看到的是，上下限变得越来越大...
AI或许会取代 coding，但在 engineering 方面仍有很长的路。对于那些足够了解AI并能高效协同的工程师，他们的价值将变得前所未有的“高级”。模型会将工程师从繁琐的“如何实现”中解放出来，更专注于“构建什么”和“为何构建”。
“品味将变得越来越有价值”。竞争力也会来源于技术品味、架构直觉和对需求的深刻洞察力。我们的主要工作，也许是向AI清晰地表达我们的意图。
构建一个沟通框架：模块化、简单、组合、文档依赖，这是目前的实践所得，也应该继续探索深化。
关于Agent
coding agent 已经足够有效且高效，不仅被市场验证，更是被公司普遍采用。大厂与创业公司都在争先恐后涌入AI IDE、CLI或是AI coding
不得不说，市面上大多数所谓的Agent，本质上是基于LLM的多轮工具调用。这更像是一种被精心编排的工作流，尽管因LLM的存在而具备了一定的不确定性和灵活性。
我越来越感受到，下一轮的agent的智能体现不仅在外部工具调用，还有工程实现的内部状态演化，不仅是上下文工程、记忆反思、缓存优化...我仍旧认为Manus走在Agent行业前沿。
继续探索...