我要投稿

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

发布日期：2025-07-19 03:41:47 浏览次数： 1527

作者：进击的大数据

微信搜一搜，关注“进击的大数据”

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 系统成熟度的试金石：

👀

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

带着疑问读代码

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

细节

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

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

其核心组件包括：

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

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

结尾

碎碎念和新闻

👀

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

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

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费场景POC验证，效果验证后签署服务协议。零风险落地应用大模型，已交付160+中大型企业