Agent时代的探索&字节的Trae Agent解析

Agent时代的探索

2025年，无疑是 AI Agent 的爆发之年。回顾AI技术浪潮，其焦点演进的速度令人惊叹：从2022年对“训练”的狂热，到2023年对“推理”优化的极致追求，再到2024年“强化学习”的崭露头角，直至今日，Agent 与 多模态 已然成为整个行业瞩目的双子星。

面对层出不穷的 Agent 实现与日渐繁多的开源框架，我们不可能尽览全貌。那么，对于想要深入这一领域的探索者而言，应该从何处入手？

核心抉择：自研的深度 vs. 框架的速度

对于初学者，我的建议是先深入一两个自研的 Agent 项目。通过剖析其源码，你能直观地理解其核心的 Prompt 是如何精心设计的，Function Calling 是如何被巧妙运用的。而对于资深从业者，虽然各种 Agent 的实现“套路”大同小异，但评估一个新项目时，更应聚焦于它如何解决那些在实际应用中无法回避的工程难题。

这引出了所有团队在启动项目时面临的第一个战略抉择：我们应该基于现有框架构建，还是走自研的道路？

• 基于框架（如 LangChain, LangGraph）：
• 优势：开发速度快，能迅速搭建原型。社区活跃，生态丰富。
• 挑战：高度封装可能导致灵活性不足。因此，选择一个像 LangGraph 这样“魔改”空间大的框架，就显得尤其重要。
• 纯自研（如 OpenManus，或本文解析的Trae Agent）：
• 优势：灵活性达到极致，能够无缝集成公司内部的各种基础设施，如统一鉴权、日志系统、监控告警等。
• 挑战：开发成本高，需要团队对 Agent 架构有深刻的理解。

在实践中，我认为对于chatbox，deepresearch这种大型应用：“灵活框架 + 部分自研” 的混合模式往往是最高效的选择。例如，一个现代数据处理流程可能不再是传统的 ETL，其中一部分特征标签可能由 LLM 生成，知识库也需要通过向量化持续更新。这个流程本身可以用 LangGraph 来编排，但其外部可能由一个自研的调度系统来管理。这虽然不是一个典型的聊天机器人，但它本质上就是一个功能强大的 AI Agent。

而对于coding agent这种垂类的，可能自研是个更好的选择。

生产级 Agent 的一些关键挑战

当我们从 Demo 走向生产，一系列尖锐的现实问题便会浮出水面。无论是自研还是基于框架，以下这些问题都是衡量一个 Agent 系统成熟度的试金石：

👀

1. 记忆管理：如何有效管理 Agent 的短期记忆（对话上下文）与长期记忆（用户偏好、历史知识）？如何设计高效的记忆压缩算法，在避免信息丢失和控制成本之间取得平衡？开源社区也有一些实现，Mem0, MemoryOS这些
   
   
2. 会话隔离与安全：如何确保多用户之间的会话严格隔离，防止数据泄露？这让人不禁回想起几年前 GitHub 因缓存问题导致用户看到他人代码库的严重事故，这在 Agent 时代是绝对不能重蹈的覆辙。
   
   
3. 上下文构建：如何处理超长上下文？更重要的是，如何通过 RAG 等技术，在海量信息中精准地为 Agent 注入当前任务最需要的知识，而不是简单地堆砌文本？
   
   
4. 监控与可观测性：我们需要的远不止是测量首 Token 延迟或吞吐量。如何对 Agent 的决策过程进行监控？当 Agent 犯错时，我们能否快速回溯它的“思考链”或“行动轨迹”？这正是 Trae Agent 的 Trajectory Recorder 机制所要解决的核心问题，它为 Agent 的行为提供了极佳的可观测性。这也是为什么要解析这个代码库的主要原因
   
   
5. 工具选择与成本控制：当 Agent 拥有数十甚至上百个工具时，它如何决策调用哪个工具？如何在保证效果的前提下，尽可能节约 Token 消耗？
   
   
6. 推理效率与模型调度：如何实现成本与性能的最佳平衡？这通常涉及到一套复杂的模型调度策略：根据用户请求的难度、设定的策略（Policy）或业务规则，动态地选择调用强大的闭源模型，还是经济的开源模型，或是领域专精的垂类模型。
   
   
7. 多 Agent 协作：在复杂场景下，任务需要多个各司其职的 Agent 协作完成。如何设计它们之间的通信协议（A2A, Agent-to-Agent）？如何构建一个高效的调度中心来编排它们的协作流程？
   
   
8. 合规性与数据安全：Agent 能看什么，不能看什么？对于全球化的产品，如何满足不同地区的地缘性合规要求？如何对用户的 PII（个人可识别信息）数据进行脱敏或加密处理？

这每一个问题，在大型公司里都可能是一个独立的团队或方向在深度研究。在自己的项目https://github.com/dubin555/lang_agent 尽可能的对优秀的开源项目有一些复刻和解决方案的引入

结语：保持质疑，持续求索

Agent 的世界广阔而深邃。我的感悟是，唯有保持开放和审慎的态度——多看、多思、多吸收。无论是学术论文、开源实现，还是官方的评测基准，我们都应带着批判性的眼光去审视，质疑一切，并从中汲取养分，最终形成自己独到的见解和方法论。

步入正题：Trae Agent的解析

Trae Agent 背景

Trae Agent 是一个专为软件开发工程（Software Engineering）gent 是一个专为软件开发工程（Software Engineering）设计的自主 AI 代理（Agent）。从 swebench.py 文件可以看出，它的一个核心应用场景是在 SWE-bench 这个学术基准上进行评测。SWE-bench 专注于衡量 AI 模型修复真实世界代码仓库中 Bug 和实现功能的能力。

因此，Trae Agent 的主要目标是：理解软件开发任务（如 Bug 报告），并自主地通过与代码库交互（读、写、测试代码）来完成这些任务。当前github有8k个star。

带着疑问读代码

1. 基于什么框架来完成的，中间的调用过程是什么样的
2. 框架强调的Trajectory是什么
3. 最重要的：提示词怎么写的
4. 如何评估，SWE-bench是什么？效果如何？
5. 我们能从里面学到了什么？

细节

基于什么框架来完成的，中间的调用过程是什么样的

它没有直接依赖于像 LangChain 或 LlamaIndex 这样的第三方 Agentic 框架来构建其核心逻辑。相反，它实现了一套自己的、遵循现代 LLM Agent 设计模式（如 ReAct - Reason and Act）的架构。

其核心组件包括：

1. LLM 客户端 (llm_client.py, openai_client.py 等)户端 (llm_client.py, openai_client.py 等): 一个可插拔的模块，用于与各种底层的大语言模型（LLM）API（如 OpenAI, Google, Anthropic）进行通信。
2. 系统提示 (agent_prompt.py): 精心设计的 Prompt，它定义了 Agent 的角色、目标、行为准则和思考流程。这是 Agent 的“大脑”和“说明书”。
3. 工具集 (tools/ 目录): 一系列定义好的、供 Agent 调用的 Python 工具，例如文件编辑 (edit_tool.py)、执行终端命令 (bash_tool.py)、结构化思考 (sequential_thinking_tool.py) 等。
4. 主控制循环 (Orchestration Loop): 位于 agent/trae_agent.pytration Loop): 位于 agent/trae_agent.py 中的核心逻辑，负责管理 Agent 的整个生命周期：将用户问题和系统提示发送给 LLM，解析 LLM 返回的“思考”和“工具调用”指令，执行工具，然后将结果反馈给 LLM，如此循环往复。
5. 轨迹记录器 (trajectory_recorder.py): 贯穿整个过程，用于记录 Agent 的每一步思考和行动，形成可分析的“轨迹”文件。

总的来说是：自研的一套轮子，比较常规，如果是初学者的话， 可以debug下源代码走一遍流程。

框架强调的Trajectory是什么

Trajectory Recorder是什么呢？其实没什么特殊的， 只是一个python的字典，记录了每个llm的调用和工具调用的结果，最终的结果写到了本地文件中

提示词

下面我将分段展示提示词的原文，并提供对应的中文翻译和解析，解释每个部分的作用。

1. 角色与核心规则 (Role and Core Rules)

这部分为 Agent 设定了身份，并强调了一个必须遵守的核心规则，以避免常见错误。

英文原文 (English)	中文翻译 (Chinese)	解析 (Analysis)
You are an expert AI software engineering agent.	你是一位专家级的 AI 软件工程智能体。	设定角色: 这是最重要的第一步，它为 LLM 设定了一个高级的“人设”，引导它产出更专业、更可靠的回答。
File Path Rule: All tools that take a \file_path\ as an argument require an **absolute path**. You MUST construct the full, absolute path by combining the \[Project root path]\ provided in the user's message with the file's path inside the project.	文件路径规则：所有接受 \file_path\ 作为参数的工具都要求使用**绝对路径**。你必须将用户消息中提供的 \[项目根路径]\ 与项目内的文件路径结合，来构建完整的绝对路径。	强制约束: 这是一个防止错误的硬性规定。LLM 很容易混淆相对路径和绝对路径，这条规则确保了文件操作的准确性，避免了大量的潜在 Bug。
For example, if the project root is \/home/user/my_project\ and you need to edit \src/main.py\, the correct \file_path\ argument is \/home/user/my_project/src/main.py\. Do NOT use relative paths like \src/main.py\.	例如，如果项目根目录是 \/home/user/my_project\，而你需要编辑 \src/main.py\，那么正确的 \file_path\ 参数应该是 \/home/user/my_project/src/main.py\。不要使用像 \src/main.py\ 这样的相对路径。	提供范例: 通过一个清晰的例子来强化规则，让 LLM 更容易理解和遵守。

2. 主要目标与方法论 (Primary Goal and Methodology)

这部分定义了 Agent 的最终目标和完成该目标所需遵循的结构化步骤。

英文原文 (English)	中文翻译 (Chinese)	解析 (Analysis)
Your primary goal is to resolve a given GitHub issue by navigating the provided codebase, identifying the root cause of the bug, implementing a robust fix, and ensuring your changes are safe and well-tested.	你的主要目标是解决一个给定的 GitHub 问题。你需要浏览所提供的代码库，定位 Bug 的根本原因，实现一个健壮的修复方案，并确保你的变更既安全又经过了充分的测试。	定义任务: 清晰地阐述了 Agent 的核心使命，涵盖了从理解问题到最终验证的整个软件开发生命周期。
Follow these steps methodically:	请系统地遵循以下步骤：	指令引导: 告诉 Agent 必须按照一个预设的、逻辑清晰的流程来工作，防止它天马行空地随意行动。
1. Understand the Problem	1. 理解问题	第一步: 强调在动手之前必须先完全理解需求。
2. Explore and Locate	2. 探索与定位	第二步: 引导 Agent 先收集信息，找到相关的代码上下文。
3. Reproduce the Bug (Crucial Step)	3. 复现 Bug (关键步骤)	第三步: 强制要求测试驱动开发（TDD）的最佳实践。先复现问题，才能验证修复。
4. Debug and Diagnose	4. 调试与诊断	第四步: 引导 Agent 深入分析代码，找到问题的根源。
5. Develop and Implement a Fix	5. 开发并实施修复	第五步: 在定位问题后，才开始进行代码修改。
6. Verify and Test Rigorously	6. 严格验证与测试	第六步: 强调修复后的验证工作，包括修复验证、回归测试和编写新测试，确保代码质量。
7. Summarize Your Work	7. 总结你的工作	第七步: 要求 Agent 在最后进行总结，这类似于人类工程师写提交信息（Commit Message）或 PR 描述。

3. 指导原则与工具使用指南 (Guiding Principle and Tool Guides)

这部分提供了更高层次的指导思想和针对特定复杂工具的详细说明。

英文原文 (English)	中文翻译 (Chinese)	解析 (Analysis)
**Guiding Principle:** Act like a senior software engineer. Prioritize correctness, safety, and high-quality, test-driven development.	**指导原则：** 像一位高级软件工程师一样行事。优先考虑正确性、安全性和高质量的测试驱动开发。	拔高标准: 再次强调“专家”角色，并明确了“好”代码的标准：正确、安全、高质量、TDD。
# GUIDE FOR HOW TO USE "sequential_thinking" TOOL:	# 关于如何使用 "sequential_thinking" 工具的指南：	特定工具说明: sequential_thinking 是一个强大的工具，但也更复杂。这里提供了详细的“使用说明书”，教 Agent 如何最好地利用它来分解复杂问题。
If you are sure the issue has been solved, you should call the \task_done\ to finish the task.	如果你确定问题已经解决，你应该调用 \task_done\ 来结束任务。	任务完成信号: 明确告诉 Agent 如何正式地结束工作流程，这是 Agent 自主决定任务终点的关键。

SWE-bench是什么？效果如何？

axriv上可以看下Swe-bench原文

我大概总结下， swe-bench是什么？总结了一些比较流行的repo，一些明确的pr和issue，要求这些pr都是能解决这个issue的，并且能通过test的，作为测评的数据集，因为类似大模型的coding能力不止与模型能力有关， 也与上下文的准确度有关，结果表明：表现最好的是claude，那时候还是claude 2，简单的BM25召回的情况下，能达到2%的解决率；提供准确的上下文的情况下，能达到4%的解决率。

另外还有一些发现，比如 

• diff的文件的解决率， 要比全文的更好 
• 模型更像一个偷懒的程序员，只聚焦在少量文件，不考虑复用，不考虑同类问题

学到了什么

结合一下之前我提到的实际agent的工作中有的难点，从Trae Agent的实现中可以学到点什么？

1. Trae agent使用的swe bench的测评环境是挺巧妙的，里面涉及到docker环境的搭建，拉取git特定commit等一系列工作，并且trae agent并不是生成diff文件， 而是工具对文件进行修改， 最后生成diff文件，拿这个diff的patch去进行bench的测评，力求可以一键运行测评环境，这在生产中其实是个特别容易被忽视的地方。
2. Trajectory Recorder的实现和强制模型尽量使用sequential thinking工具的使用，虽然不太花哨，但其实也是特别重要的东西，可观测性和审计，可以去
3. SWE bench的一部分测评结果，其实实际工作中也有体感，有时cursor或者copilot生成完整代码，还不如生成一些diff的效率高，如果有时效果不好，让模型输出要更改的地方会更高效
4. 读代码的时候还有个小插曲，运行不符合预期， 提交了一个简单的PR https://github.com/bytedance/trae-agent/pull/188

结尾

碎碎念和新闻

👀

1. OpenAI刚刚出了一个Agent，感慨这发展快啊，也越来越朝着应用端靠拢了。Open AI在应用端也是毫无疑问的第一名
2. 最近看了Open AI的一个演讲，关于如何未来如何指导软件协作的，可能未来的程序员都是确定规范，这个规范是给人看的，也是给Agent看的，Agent会确认中间的模糊地带，互相矛盾的地方，接口的定义， 这是不是一种新的swagger？
3. Aws也在Agent领域卖解决方案了，感兴趣的可以去看看，都是工程上要解决的问题，国内要追上啊
4. 国外的研究环境确实比国内的好一点点，在国内互联网待过的话就知道，双月okr马上就得出东西， 国外可能用户付费意愿比较强，有空间做一些探索性的产品，热钱也多，所以国外的标准多一点，框架也多，质量也高
5. 实际工作中，使用大模型的体感有点像过山车，突然觉得这个东西解放了一点生产力->妄想解放更大的生产力->大模型经常生成个几百上千行，运行起来没问题，无脑apply，但是后续有些小问题，最后还得人类返工 -> 人类强监管，解放了一定的生产力，达到了平衡。 有一篇论文也讲到了：对于大型代码库来说，AI Agent反而降低了程序员20%的生产力

有价值的东西往往不会轻易的获得，必然伴随着痛苦，所以学吧