前言

最初，AI 编程体现为 AI Chat 模式，开发者在对话框中提问，大模型则返回包含代码块的 Markdown 响应。这是一种典型的“代码片段”模式，开发者需要手动复制、粘贴、修改，模型扮演的是一个“增强版搜索引擎”的角色。这种模式的局限性显而易见：代码零散、缺乏上下文、无法直接运行。

随后，业界演进出了 Artifacts（产物）模式。以 V0 等产品为代表，通过特定的 Prompt 词或 XML 标签引导，模型可以在一次交互中生成一个完整（但通常非常简单）的前端项目代码。后端服务解析这些结构化输出，自动创建文件，从而交付一个可直接运行的迷你项目。然而，受限于模型的输出 Token 限制，这种方式难以应对包含数十个文件、逻辑复杂的大型项目。

真正的挑战在于：如何让 AI 在大型项目的迭代中持续发挥作用？这要求 AI 具备在多轮会话中理解需求、记忆上下文、并逐步完成任务的能力。正是为了解决这一核心问题，AI Agent 的概念应运而生，并催生出两种主流实现路径：工程驱动与模型驱动。

  • 工程驱动 (Engineering-Driven)：定义一套固定的、可预测的工作流（Workflow）。例如，Copilot Workspace 的早期版本，会严格遵循“生成计划提案 -> 用户确认 -> 生成实现计划 -> 用户确认 -> 生成代码”的线性流程。这种方式稳定可靠，但灵活性较差。

  • 模型驱动 (Model-Driven)：基于模型一系列“工具（Tools）”，让模型自主决策在何时、以何种顺序调用哪些工具来达成用户目标。以 Lovable 等为代表，这种方式更加灵活、更贴近“智能体”的理念，但其行为的不确定性也更高。

随着技术的发展，模型驱动逐渐成为主流，并塑造了我们今天对 AI Agent 的普遍认知：一个具备多轮迭代能力、能够主动思考、并通过调用工具来感知上下文与执行任务的智能系统。TRAE 的 AI Agent 同样遵循了这一演进脉络，并通过三个大版本的迭代，在工程驱动和模型驱动之间找到了独特的平衡。

TRAE V1.0

TRAE 的第一个 AI Agent 版本，深受早期 AI Chat 模式和工程驱动思想的影响，其核心特点是拥有一个固定的、可预测的工作流。当用户提出一个开发需求时，系统会严格按照以下步骤执行：

TRAE 1.0 核心工作流：

  1. 需求扩写 (Proposal Generation)：首先，系统不会直接处理用户的原始输入。它会调用一次大模型，将用户相对模糊的需求，结合历史会话内容，扩写成一份详尽、结构化的任务描述，即“提案（Proposal）”。
  2. 上下文召回 (Context Retrieval)：接着，系统以这份详细的 Proposal 为依据，对当前项目代码库进行一次强制的、前置的关联性召回（RAG，Retrieval-Augmented Generation）。召回内容主要包括相关代码文件、代码片段、项目目录结构等。用户也可以通过 @file 等特殊标识符主动引入文件作为补充上下文。
  3. Agent 迭代循环 (Agent Loop)：在准备好充足的上下文后，才真正进入 Agent 的核心迭代环节。模型在一个循环中不断评估任务状态，按需调用工具（如读写文件、执行命令等），直到它判断所有需求都已满足，便会调用 finish 工具，结束本次任务。

这个设计体现了典型的工程驱动思维：流程标准化，每一步的产出和目标都非常明确。这样做的好处是稳定可控，尤其是在早期模型能力尚不完善、行为难以预测的情况下，一个固化的流程能保证任务执行的基本成功率。

工程化的代码修改机制

为了让模型生成的代码能够精准地应用到现有项目中，TRAE 1.0 探索了两种创新的工程化修改机制，规避了让模型直接输出完整文件所带来的高成本和不稳定性。

  • Fast Apply (快速应用)：通过 Prompt 引导，让模型返回一种类似 diff 的特殊 Patch 结构，其中通过注释标明哪些是已有代码、哪些是新增或修改的代码。然后，将这个 Patch 和原始文件一同交给一个专门训练过的小模型，由小模型“合并”成最终的新代码。这种方式虽然巧妙，但引入了额外的模型调用，增加了耗时，且在处理大规模变更时仍受限于小模型的上下文窗口。

  • Search & Replace (搜索与替换)：这是后续的优化方案。模型被要求输出一种包含 search 和 replace 字段的结构化数据。search 部分是待替换的源代码片段，replace 则是新的代码片段。后端服务通过工程手段执行精确的字符串查找和替换。

    • 这种方式完全脱离了对第二次模型调用的依赖，速度更快。然而，它也面临工程上的挑战：模型的输出可能存在“幻觉”，比如多一个空格、错误的换行符（Windows 的 \r\n vs. Unix 的 \n），导致 search 失败。为此，工程团队在替换逻辑中加入了模糊匹配、相似度匹配等兜底策略，以提升修改的成功率。

1.0 架构的局限

尽管 V1.0 的架构稳健，但其固有的“工程驱动”模式也带来了明显的局限性：

  1. 流程冗长，响应缓慢：即使用户只是提出一个非常简单的修改（例如“把这个变量名改一下”），系统也必须走完“扩写 Proposal -> 全局召回 -> Agent 迭代”的完整流程，给用户“反应慢”的体感。

  2. 上下文的“暴力”裁剪与遗忘：随着对话轮次的增加，传递给模型的上下文（历史消息、召回内容、工具调用历史等）会持续膨胀，最终超出模型的 Token 限制。V1.0 采用了一种简单粗暴的工程裁剪策略：按固定的优先级（如：先移除历史召回信息，再移除历史会话）丢弃信息。这直接导致了用户广为诟病的**“模型遗忘”**问题——Agent 常常记不住前几轮做过的事情。

  3. 与先进模型的“认知冲突”：当团队尝试接入更先进的模型（如 Claude 3.7）时发现，这些模型似乎并不“信任”系统在第一步就强行喂给它的召回信息。它们表现出强烈的自主倾向，更愿意自己通过调用工具（如 search_code）来获取它认为真正需要的上下文。固定的前置 RAG 流程，反而成了一种束缚。

TRAE V2.0

。这次升级的核心思想是**“将决策权还给模型”**，从工程驱动全面转向模型驱动，让 Agent 表现得更像一个真正的智能体。

2.0 架构最显著的两大改动是：

  1. 移除固定的前置工作流：取消了 Proposal 扩写和强制的全局 RAG 环节。系统不再替模型“提前思考”，而是让模型在接收到用户原始需求后，自主判断是否需要以及何时需要获取额外上下文。如果模型认为信息不足，它会主动调用 search_code_base 等工具来执行召回。这不仅极大地缩短了简单任务的响应时间，也顺应了先进大模型自主规划的内在倾向。

  2. 引入智能的上下文压缩策略：为了解决“模型遗忘”问题，V2.0 摒弃了 V1.0 的暴力裁剪方法，引入了一套更为精细的总结压缩（Summarization & Compression）策略，并在此基础上构建了“长短时记忆”系统。

长短时记忆

短期记忆 (Short-Term Memory)

  • 内容：包括 RAG 召回的代码片段、多轮对话中的工具调用历史（Tool Calls）等。

  • 特点：信息量大、时效性强、但并非所有细节都至关重要。

  • 管理策略：可压缩。当上下文窗口接近上限时，系统会启动异步的总结任务。例如，一次冗长的工具调用（Tool Call）及其返回结果，会被一次新的模型调用浓缩成一句精华摘要（如：“我阅读了 auth.js 文件，发现登录逻辑在 handleLogin 函数中实现”）。在后续的对话中，这条摘要将替代原始的、占据大量 Token 的工具调用记录，从而在保留核心语义的同时，大幅节省上下文空间。

长期记忆 (Long-Term Memory)

  • 内容：包括用户自定义的规则（Custom Rules）、模型在推理中产生的关键记忆碎片（Memory Fragments）、以及后面将提到的 ToDo List。

  • 特点：结构化、高价值、对模型行为有决定性影响。

  • 管理策略：不可压缩。这类信息必须以其最原始、最完整的形态，永久存在于每一次模型调用的上下文中。例如，用户的自定义规则“禁止使用第三方库”，如果被压缩成“尽量少用外部库”，其约束力就会大打折扣，导致模型行为偏离预期。因此，长期记忆被完整保留，确保 Agent 的核心行为准则不被扭曲。

聚焦任务

在复杂任务中，即便是最先进的模型也可能“思维发散”，偏离最初的目标。为了让 Agent 解决问题时更加聚焦，V2.0 引入了两项重要的辅助机制：

  • ToDo List (任务清单)：当模型判断用户需求较为复杂，需要多个步骤才能完成时，它会被引导先生成一个 ToDo List。这个清单就像一份微型的作战计划，将宏大目标拆解为一个个清晰、可执行的子任务。随后，Agent 会像一个严谨的程序员一样，逐项检出（check out）并完成清单上的任务。这种“先规划、后执行”的模式，极大地提升了复杂任务的完成质量和逻辑清晰度。

  • Reminder (提醒机制)：为了进一步强化模型的注意力，系统引入了 Reminder 机制，在每次与模型交互时，通过一段简短的提示来“重复重要的事情”。这就像在开会时，主持人不断强调会议议程一样。例如，当 ToDo List 发生变化（如新增或完成一项）时，Reminder 会在下一轮对话的开头明确告知模型：“请注意，任务清单已更新。”

其他关键优化

除了上述核心改动，V2.0 还在诸多细节上进行了打磨，进一步提升了 Agent 的综合能力：

  • 工具列表（Tools）的精简与升级：对 1.0 版本的工具集进行了全面的梳理和精简，移除了冗余或低效的工具。同时，全面拥抱了 Native Function Calling，替代了过去通过拼接 JSON Schema 来模拟工具调用的“土办法”。这不仅提升了与主流模型的兼容性，也使得工具的定义和调用更加规范和高效。

  • 错误感知与自我修正：提升了模型的“感知度”。当 Agent 对某个文件进行编辑后，系统会立即运行 Lint（代码风格检查）或静态分析。如果发现新的错误（Lint Error），这些错误信息会在下一轮推理时被注入到上下文中，让模型能够及时感知到自己之前的操作“搞砸了”，从而主动进行修正。这赋予了 Agent 一定程度的自我纠错能力。

TRAE V3.0

随着 TRAE 平台孵化出面向特定垂直场景的 Solo 模式（如 Solo-build，一个针对 Web App 的端到端应用生成 Agent），AI Agent 面临的挑战从“完成单个开发任务”升级为“负责整个项目的交付流程”。这意味着任务的复杂度、流程的长度、以及对专业领域知识的要求都呈指数级增长。

纯粹依赖单个通用 Agent 的 V2.0 模型驱动架构，在这种复杂场景下显得力不从心。上下文窗口的压力再次凸显，单一模型的知识和能力也难以覆盖所有专业领域。为此，TRAE 团队设计了 V3.0 架构，其核心是引入了“多 Agent 协作”与“人机循环”，回归到一种模型驱动与工程驱动深度融合的混合范式。

V3.0 架构主要建立在三大支柱之上：多 Agent 架构、并发工具调用、以及人机协同（Human-in-the-Loop）。

多 Agent 架构

V3.0 最核心的升级，是从单 Agent 模型演变为多 Agent（Multi-Agent）架构。系统不再只有一个无所不包的通用 Agent，而是演变成一个由主 Agent（Master Agent） 和多个子 Agent（Sub-Agent） 组成的“专家团队”。

多 Agent 架构的核心优势

  • 上下文隔离，大幅缓解窗口压力：这是多 Agent 架构最直接的价值。主 Agent 负责将一个宏大任务（如“帮我开发一个带用户登录功能的博客网站”）分解，并将不同的子任务（如“设计数据库 Schema”、“编写后端认证 API”、“开发前端登录页面”）分派给不同的专家子 Agent。
    • 子 Agent 只需关心自己负责的那个子任务，因此它只需要加载与该任务强相关的上下文，其记忆负担极小。
    • 主 Agent 只需关注子任务的启动和最终结果，完全不必关心子 Agent 在执行过程中的所有细节（如中间的思考、工具调用等）。
      这种“职责分离”使得每个 Agent 的上下文窗口都保持在一个极小且高效的范围内，从根本上解决了单 Agent 模式下上下文无限膨胀的问题。
  • 工具按需分配，提升决策效率：在 Solo 模式下，系统集成了大量针对特定领域的定制工具（如数据库配置、云服务部署、Figma 设计稿解析等）。如果将数百个工具全部暴露给一个 Agent，不仅会严重挤占宝贵的上下文空间，还会让模型在“选择困难症”中消耗大量算力，甚至做出错误选择。
    多 Agent 架构允许工具的按需分配。例如，DB-Agent 只会加载与数据库操作相关的工具，而 UI-Agent 只会加载与前端代码生成和 Figma 解析相关的工具。这使得每个子 Agent 的工具列表都非常简短、清晰，极大地提升了模型决策的准确性和效率。
  • 异构模型混用，发挥各自专长：不同的子任务对模型能力的要求也不同。多 Agent 架构允许为不同的子 Agent 配置最适合它的驱动模型。
    • 对于代码生成任务，可以使用像 GPT-4 Code Interpreter 或 DeepSeek Coder 这样在编码上表现卓越的模型。
    • 对于文档撰写或计划生成任务，可以使用在语言理解和长文本生成上更具优势的模型，如 Claude 3 或 Kimi。
    • 对于一些简单的、模式化的任务，甚至可以使用成本更低的小模型来驱动，以优化整体成本。
      这种异构模型混用的策略，使得整个系统能够扬长避短，在不同环节都发挥出最佳的“性价比”和效果。

并发工具/Agent 调用

为了最大化执行效率，V3.0 架构引入了并发工具调用（Parallel Tool Calling） 的能力。当模型判断多个待执行的操作之间没有依赖关系时，它可以一次性发起多个工具调用。

最典型的场景就是并发读取和并发搜索。例如，当 Agent 需要分析 service.js, controller.js, model.js 三个文件时，它可以并行发起三个 read_file 的调用，而不是串行地一个一个读取。执行耗时可以从 T1 + T2 + T3 缩短为 Max(T1, T2, T3)。

更重要的是，由于子 Agent 本身也被抽象和封装成了主 Agent 可以调用的“特殊工具”，因此，并发工具调用也就自然地支持了子 Agent 的并发执行。当主 Agent 发现“分析数据库”和“设计 Logo”这两个子任务可以同时进行时，它就能并行启动 DB-Agent 和 Design-Agent，让它们同时工作，从而极大地缩短了项目的总体交付时间。

值得一提的是，分享者指出，不同模型对于并发调用的“倾向性”存在差异。例如，GPT 系列模型表现出更强的并发意愿和更好的并发效果，而某些其他模型则倾向于更保守的串行调用。这再次印证了针对不同模型进行精细化 Prompt 调优和策略适配的重要性。

人机协同（Human-in-the-Loop）

纯粹的模型驱动在面对超长、超复杂的任务时，一个核心痛点是“脱缰”风险——Agent 可能会在长达数十分钟的自主运行后，交付一个与用户预期南辕北辙的结果，造成巨大的时间和算力浪费。

为了解决这个问题，V3.0 架构将**“人”作为最重要的一个环节，重新请回了决策循环**，构建了完善的 Human-in-the-Loop (HIL) 机制。系统在执行流程中的某些关键决策点（Critical Checkpoints） 会主动暂停，将阶段性成果呈现给用户，并等待用户的确认或反馈，然后再继续执行。

典型的 HIL 场景

  • 0-1 生成时的文档确认：在从零开始创建一个新项目时，Agent 会先生成 PRD（产品需求文档）和技术设计文档。此时，它会暂停并等待用户审阅。用户可以提出修改意见让 Agent 自行迭代，也可以直接上手修改文档，直到满意后才授权 Agent 进入下一步的编码阶段。

  • 第三方服务集成配置：当需要集成某个第三方服务（如配置 OpenAI API Key 或数据库连接字符串）时，Agent 会生成配置文件模板并暂停，等待用户填入敏感的密钥或个性化信息，然后再继续后续的自动化集成和部署流程。

  • 需求追加与动态调整：通过一个持续展示的消息列表，用户可以随时在 Agent 执行过程中追加新的小需求或修正指令，从而降低了“打断-重来”的高昂成本。

像“在 PRD 确认前必须暂停”这类具有 100% 确定性要求的业务逻辑，如果完全交给模型来决策，即使 Prompt 优化得再好，也无法保证绝对的可靠性。因此，V3.0 选择通过工程手段，在可识别的关键场景进行强制性的流程终止，等待用户交互。

模型驱动和工程驱动并非非黑即白的对立关系，而是相辅相成的共生关系。模型负责发挥创造性、进行自主规划和执行，而工程则负责构建稳固的“护栏”，在关键路径上进行引导、干预和兜底，确保整个系统的可靠性和最终交付质量。后 AI 时代，一个优秀的 Agent 系统，必然是模型智能与工程智慧的结晶。

Trae 开发的一些经验分享

核心思想是：“把 AI 当作一个能力极强，但需要清晰引导的实习生。” 要从 AI Agent 获得满意的结果，用户的提问和引导通常需要满足三个条件：

  1. 充足的上下文 (Sufficient Context)：如果信息缺失，模型就需要花费额外的轮次去获取，导致速度变慢，甚至可能因为获取到错误的上下文而“走上歧途”。

  2. 清晰的意图 (Clear Intent)：如果目标模糊，模型的执行过程就容易发散，做出超出预期的行为。

  3. 匹配的能力 (Matched Capability)：如果任务超出了模型当前的能力范围（如处理超大规模数据），强行执行只会得到低质量甚至错误的结果。

基于这三大原则，分享者给出了一些具体的日常使用 Case：

高效使用 AI Agent 的技巧

  • 主动圈选，胜于让 AI 去猜：虽然 Agent 具备自主获取上下文的能力，但最高效的方式永远是在提问时，手动将被影响或需要被关注的代码范围圈选出来。这能极大地减少模型猜测和搜索的时间，直达问题核心。
  • 让 AI “授人以渔”，而非“授人以鱼”：当面临大规模的数据处理或分析任务时，不要将庞大的数据文件直接丢给模型，期望它处理后返回结果。这会迅速耗尽上下文窗口。更聪明的做法是，向 Agent 清晰地描述你的数据结构、处理目标和具体步骤，让它为你编写一个数据处理脚本（如 Python 脚本）。然后，你只需在本地执行这个脚本即可。分享者在做成本专项分析时，就通过这种方式让 Agent 生成了大量 Python 脚本来处理线上用户数据。
  • 用“外部知识”武装你的 Agent：当面对你不熟悉的、或公司内部的专有技术框架时，可以利用 TRAE 的文档导入功能。将相关的官方文档或内部 Wiki 导入后，Agent 就能基于这些精准的“外部知识”来回答你的问题或编写代码，效果远胜于依赖其泛化的内部知识。
  • 通过“自定义 Agent”打造你的专属助理：TRAE 的自定义 Agent 功能为高级用户提供了极大的灵活性。分享者举了两个有趣的例子：
    1. 构建长期项目记忆：他曾创建一个自定义 Agent，并用 Prompt 指导它在每次会话结束后，将本次任务的关键信息和对项目的理解，更新到一个名为 memory.md 的文件中。通过这种方式，Agent 就拥有了一个跨会话的、真正的“长期记忆”。
    2. 教会 Agent 使用新工具：他曾通过 Prompt，教会一个自定义 Agent 如何使用一个名为 Task Master 的命令行任务管理工具，从而让这个 Agent 具备了专业的任务拆解与管理能力。这揭示了一个强大的范式：你可以通过 Prompt，将任何命令行工具（CLI）的能力，赋予给你的 AI Agent。

在分享中，一个被称为 COT (Chain of Thought，思维链) 的 Prompt 技术被反复提及，并被誉为能“极大提升准确率”的关键技巧。

COT 的核心思想是：在要求模型输出最终答案之前，先引导它输出一步步的分析过程。 这个“自我反思”的过程，能够显著提升模型在复杂决策任务上的逻辑准确性。

分享者举了一个精彩的实战案例来说明 COT 的威力。在设计“执行命令行”这个工具时，有一个布尔类型的参数 blocking，用于决定命令是同步执行还是异步执行。例如，运行一个 HTTP 服务器（如 npm run dev）需要异步（blocking: false），否则会卡住整个流程；而安装依赖（如 npm install）则需要同步（blocking: true）。

团队最初发现，无论如何优化 Prompt，模型在判断 blocking 参数时总有一定概率出错，导致流程卡死。最终的解决方案，就是典型的 COT 应用：

他们在要求模型输出 blocking 字段之前，增加了一个要求：先输出一个名为 command_type 的字段，用于对即将执行的命令进行分类（如 WEB_SERVER, INSTALL_DEPENDENCY, FILE_OPERATION 等）。

{
  "tool": "execute_command",
  "command": "npm run dev",
  "command_type": "WEB_SERVER", // COT 步骤：先分析命令类型
  "blocking": false             // 最终决策：基于分析，做出准确判断
}

这个新增的 command_type 字段，本身没有任何工程代码会去消费它。它的唯一目的，就是充当模型思考的“草稿纸”，强制它在决定 blocking 的值之前，先对命令的性质进行一次显式的分析和归类。正是这简单的一步，让模型判断的准确率得到了大幅提升。这个案例生动地诠释了 COT 在提升模型决策可靠性方面的巨大价值。