做一个 AI Agent 没那么简单，也没那么玄

date

Oct 26, 2025

slug

building-ai-agents-practical-guide

status

Published

summary

做一个 AI Agent 不只是给 LLMs 加几个工具那么简单。本文基于实践经验，探讨 Agent 设计中的三个核心问题：上下文管理、工具设计和评估体系。从 OpenAI AgentKit 和 Anthropic 多智能体研究系统的经验出发，分享关键词检索 vs 向量检索的选择、为什么 Agent 不需要专门训练模型、以及产品设计流程如何因 AI 而改变。

先叠个甲：我谈的 Agent 是什么

在开始讨论之前，我想先明确一下，本文讨论的 Agent 到底是什么。因为我发现很多人对 Agent 有一些不切实际的期待，或者说是误解。

有些人在谈 Agent 的时候，想象的场景是：以后公司都不用雇人了，直接雇佣 Agent，想裁就裁，不用赔偿，不用交五险一金，完美！但老实说，这根本不是目前 Agent 要做的事情，目前也根本做不到。甚至我认为，在大语言模型这个技术架构下，可能也很难实现我们想象中的那种真正的、完全自主的人工智能。

那我们谈的 Agent 是什么呢？简单来说，就是一个能自主使用工具、完成特定任务的 AI 系统。它的核心特征是：给它一个目标，它可以自己规划步骤，调用各种工具（比如搜索、读取文件、调用 API），然后一步步完成任务。这听起来很强大，但请注意我说的是「特定任务」。

目前的 Agent 擅长的是什么？是那些边界相对清晰、可以分解为具体步骤的任务。比如：

搜索多个来源的信息并综合成一份研究报告

根据需求查询数据库、分析数据、生成可视化图表

读取代码库、定位 bug、生成修复方案

根据用户问题查询知识库、整理相关文档

这些任务有一个共同特点：它们是「工具密集型」的。Agent 的价值不是它有多聪明，而是它能够灵活地组合使用各种工具，完成需要多个步骤的复杂任务。人类做这些事情当然也可以，但是很耗时间。Agent 的价值是提高效率，而不是替代人的判断。

那 Agent 不擅长什么？几乎所有需要真正理解、创造、判断的工作。比如：

理解一个复杂业务场景的深层次需求

做出涉及多方利益权衡的战略决策

处理需要同理心和人际敏感度的沟通

在高度不确定的情况下做出创造性的突破

这不是说 Agent 完全不能辅助这些工作，但它无法替代人在这些场景中的核心作用。我做 Agent 这段时间最深的感受是：Agent 是一个很好的助手，但它不是一个员工。它能帮你快速完成很多琐碎的、重复的、需要大量信息处理的工作，让你有更多时间去思考、去做真正需要人类智慧的事情。

为什么我说大语言模型架构可能很难实现真正的人工智能？因为我个人还是觉得目前的 LLM 本质上是一个强大的模式识别生成器。它能从海量数据中学习到语言的模式、知识的模式、推理的模式，然后在新的场景中应用这些模式，但是这样的他也只是基于训练数据中的模式做出了看起来合理的回答。尽管在训练中，看到了人类专家终其一生都学不完的数据，但是它们能做的很多任务依然还远不如人类专家，所以我感觉它们在泛化能力上还有非常大的欠缺。（都是我个人看法）

这不是说 LLM 不强大，恰恰相反，它在很多任务上已经非常实用了。但我们需要清醒地认识到它的局限性，这样才能正确地使用它，做出合理的产品决策。

因此，我在这篇文章里谈的是如何构建一个能够自主完成特定任务、提高工作效率的 AI 工具。

上下文管理：核心问题

假设说做一个 Deep Research，让 AI 像人类研究员一样工作，它需要搜索多个来源，阅读大量文档，综合分析信息，最后生成一份有深度的研究报告。

想象一下这个场景：让 Agent 研究一个复杂话题，比如「中国金融科技的监管演进与未来趋势」

然后你点一下，哇撒，Agent 开始工作了，它搜索了十几个相关网页，读取了好长的文档，收集了大量的政策信息、市场数据和专家观点。这时候你会发现，所有这些信息都被塞进了 Agent 的上下文窗口中。起初这不是问题，但随着研究深入，上下文开始膨胀。很快就超出了模型的上下文，而这个时候研究还远远没有结束。

比如说你可能听说过「Lost in the Middle」这篇论文，它发现模型对上下文开头和结尾的内容关注度最高，而中间部分很容易被「遗忘」。不过需要说明的是，这篇论文是针对 GPT-3.5 Turbo 那个时代的模型做的测试，现在的旗舰模型在这方面已经好很多了，而且后续也有一些论文并未完全验证当初的结论。

但这不意味着上下文管理不重要了。在我看来，最大的问题其实不是所谓的「上下文腐败」，而是上下文不够用。理论上，现代大模型都有很大的上下文窗口，几十 K 甚至 1M tokens，但实际情况是，当你真正用到一些复杂的任务上，可以很轻松把上下文塞满时。

很多时候不是模型处理不了这么长的上下文，而是你的任务还没完成，上下文就满了。就像一个研究员的笔记本，问题不是他理解不了复杂内容，而是笔记本的页数有限，研究还没做完，笔记本就写满了。

那怎么办呢？我开始思考一个本质问题：Agent 到底需要记住多少东西？是所有的工具调用结果都要保留吗？还是可以选择性地遗忘一些？当我们做一个复杂研究时，我们通常不会想着自己搞定所有的事情，而是可以分派出去一些任务，后续只需要知道结论就行了。同时我们也不会记住每一个细节，而是会记住核心问题、关键发现等等，而具体的数据和细节则记在笔记里，需要时再翻看。

多智能体

你可以把它想象成一个研究团队的工作方式。团队里有一个项目负责人，他负责理解研究目标，制定研究计划，协调团队成员的工作。然后有几个研究员，每个人负责一个特定的子课题，他们独立工作，深入研究自己负责的那个方向。最后可能还有一个写作专家，负责把所有研究成果整合成一份连贯的报告。这样的分工有什么好处？

每个人的工作范围是明确的，他们不需要记住整个项目的所有细节，只需要专注于自己的那部分工作，这样效率会高得多，质量也更有保证。

这种多智能体的思路带来的核心改善是：每个智能体有自己独立的上下文窗口，它们之间通过明确的消息传递来协作。每个智能体在接收任务时，会得到一个清晰的目标描述和必要的上下文信息，而不是整个项目从头到尾的完整历史。这样可以避免单个上下文过度膨胀，同时每个智能体也能更专注于自己的工作。

这方面 Anthropic 分享的关于他们如何构建多智能体研究系统的文章很有启发。他们构建了 Claude Research 功能，采用的就是一个 Lead Researcher（主研究员）加多个 subagents（子智能体）的架构。Lead Researcher 负责理解查询、制定研究策略并将计划保存到 Memory 中，然后创建多个 subagents 并行搜索不同方面的信息。这种架构在他们的内部评估中，使用 Claude Opus 4 作为 lead agent 和 Claude Sonnet 4 作为 subagents 的多智能体系统，在研究任务上比单一的 Claude Opus 4 提升了 90.2% 的性能。

特别是对于需要广度优先搜索的任务，比如找出 S&P 500 信息技术板块所有公司的董事会成员这种需要同时探索多个独立方向的查询，多智能体系统能够通过并行处理大幅缩短研究时间。Anthropic 提到，他们发现 token 使用量本身就能解释 80% 的性能差异——多智能体系统通过让每个子任务有独立的上下文窗口，可以处理远超单个 200,000 token 限制的信息量。

当然，这种思路也有弊端。你需要设计好智能体之间的通信方式，决定什么信息需要传递，什么信息可以省略。有时候你会发现，某些上下文信息在多个智能体之间都需要，这时候你要判断是让它们共享这部分上下文，还是通过摘要的方式传递关键信息。

而且 Anthropic 的文章也说，多智能体系统会消耗大量 tokens——agents 使用的 tokens 是普通对话的 4 倍，而多智能体系统则是普通对话的 15 倍。这意味着如果你在简单任务上使用多智能体系统，会面临高昂的计算成本。这就需要根据具体场景来决定了。

压缩、摘要与检索：其他上下文管理策略

除了多智能体的思路，还有一些其他的上下文管理策略在实践中也很有用，比如说 https://youtu.be/6_BcCthVvb8 分享的压缩和摘要（又叫上下文卸载）。

想象你的 Agent 读取了一篇很长的文档，几万字的内容。如果把整篇文档都保留在上下文中，很快就会爆炸。但如果你让 Agent 读完后提取关键信息，生成一个摘要，那么后续就只需要保留这个摘要，而原文可以暂时存放到他处。这就像人类做笔记，我们不会把整本书都抄下来，而是记录关键观点和结论。

压缩和摘要不完全一样。

压缩是可逆的，比如在对话历史中将获取到的文章保存到硬盘里面，对话历史中里包含这篇文章的路径；

而摘要是不可逆的，提取文章的核心观点到对话历史中，这样虽然会丢掉很多细节，但是不需要额外进行硬盘上的管理。这两种方法各有适用场景。

然后是检索，当信息被卸载后，Agent 需要能按需检索相关内容，这里主要有两种方法：

语义搜索和索引：像很多之前 ChatXXX 工具一样，通过向量数据库进行语义匹配

文件系统和简单搜索工具（我称之为关键词检索）：像 Claude Code 使用的方法，依靠 grep、glob 等传统工具

分享的人说 Manus 选择后者，每个会话都是新的沙盒环境，没有时间建立索引。当然我觉得不仅仅是「没时间建索引」这么简单，主要还是没必要，这是任务本质决定了检索方式。

对检索方式的思考

这个话题值得展开讲讲，因为它涉及到一个很常见的误区。很多人一提到 AI 检索，就会想到向量检索、语义搜索、RAG 这些听起来很「AI」的技术。向量检索确实很强大，它能找到语义相似的内容，即使没有关键词匹配也能工作。但问题是，它真的适合所有场景吗？

在我做 AI 产品的相关实践中，发现当你在处理研究任务时，你要找的东西往往是精确的概念。比如你想找某个政策的具体内容，某个数据的来源，某个专家的观点，这些都有明确的名称或关键词。在这种场景下，关键词检索能精确找到所有相关位置，速度极快，几乎是毫秒级的，而且成本几乎为零。最重要的是，你清楚地知道为什么找到这些结果，因为它们包含你搜索的关键词。

相比之下，向量检索在这个场景反而是劣势，它需要先把所有内容转成向量，这本身就有成本，不管是时间成本还是 API 调用成本，然后做相似度计算，又是成本。最后可能返回一些「语义相似」但实际不相关的结果。比如你搜「普惠金融政策」，它可能返回包含「金融服务创新」的内容，因为语义相似，但这可能不是你要的，而且你很难解释为什么它返回了这些结果。

让我用一个更具体的例子来说明。假设你在研究一个复杂的市场话题，Agent 在过程中收集了几十份文档，包括政策文件、行业报告、新闻文章等等。1 个小时后，撰写到订阅制商业模式的时候，这时候用关键词直接搜索所有保存的文件中包含「订阅」或「subscription」的内容，几十毫秒就能精确定位，然后 Agent 可以快速回顾相关内容给出答案。

这比建立向量索引然后做语义搜索要快得多、准得多、便宜得多。

这不是说向量检索不好。它的价值在于处理模糊的、概念性的查询。比如在一个记忆系统中，用户说「我上次提到的那个关于投资的想法」，系统需要从数百条记忆中找出语义相关的那几条。这种模糊的查询，向量检索才有价值。或者在分类场景，判断一个用户反馈是属于「功能请求」还是「bug 报告」，这是典型的文本分类的应用。情感分析也是类似，把文本映射到情感空间中的某个位置。

所以我的结论是：检索方式的选择应该基于任务的本质。如果你的任务涉及明确的概念、术语、名称，那么关键词检索往往是最优选择。如果你的任务是模糊的情感识别、文本分类或模式识别，那么向量检索更合适。

现在很多 RAG 系统都在搞混合检索，先用关键词检索保证精确召回，然后用向量检索补充语义相关的内容，最后再重排序。这种架构的存在本身就说明，单纯的向量检索是有局限性的。

比如说 Claude Code 也选择了关键词检索而不是向量检索，它们处理的是代码，从用户的任务中通常就能知道要找什么函数、什么 API，关键词检索就能精确定位。代码场景对精准性要求很高，你需要找到特定函数的调用位置，特定变量的定义，这些都有明确的名称。

比如你搜 openDatabase，它可能返回包含 connectToStorage 的代码，因为语义相似，但这可能不是你要的。

同时还有一个容易被忽视的成本问题。关键词检索扫描几十万行代码只需要几十毫秒，完全在内存中操作，没有额外成本。而向量检索首先需要调用嵌入模型把代码库转成向量，假设用 OpenAI 的嵌入模型，几十个文件可能就要花费十几美元，然后存储在向量数据库中，又是基础设施成本，查询时要算相似度，还需要维护索引的更新。对于需要控制成本的产品来说，这些都是实实在在的开销。

工具设计：从基础到抽象的分层思考

Manus 分享了一个三层抽象的结构。

最底层是原子级函数，大约只保留 10 到 20 个最基础的操作，比如读写文件、执行 shell 命令等等，保持动作空间紧凑。这一层就像编程语言的基本语句，你不会频繁修改它们，因为它们是基础。

第二层是沙盒工具，将更多能力卸载到预安装的命令行工具中，智能体通过 shell 调用它们。这避免了函数调用空间的膨胀，而且工具可以像 Linux 命令一样被发现，比如使用 --help 参数来查看使用方法。这一层的巧妙之处在于，它利用了现有的工具生态，而不是试图在函数定义层面重新发明轮子。

第三层是包和 API，智能体可以编写 Python 脚本调用预授权的 API 或库。这对处理大量数据特别有效，因为计算在运行时完成，只返回摘要到上下文中，大大节省了 token 开销。而且这给了 Agent 最大的灵活性，它可以根据具体需求组合使用各种功能。

这种设计的优雅之处在于：从模型的角度看，三层都通过标准函数调用访问，保持了接口简单和缓存友好性。也就是说，对于模型来说，调用一个基础函数和调用一个高级功能没有区别，它们都是函数调用。这种统一的接口设计让系统更容易理解和使用。

Manus 的分享还提到了一个重要原则：「少构建，多理解」（Do less, understand more）。他们说 Manus 最大的进步来自简化和删除不必要的技巧，而不是增加更复杂的管理层。这个观点我深有体会。很多时候我们会觉得加一个新功能、加一个新工具能解决问题，但实际上可能让系统更复杂。真正的改进往往来自于删除冗余，简化流程。

比如他们提到早期版本使用 todo.md 文件做规划，结果浪费了三分之一的操作在更新待办列表上。后来他们用独立的规划智能体替代了这种方式，更简洁高效。这个例子很有启发性：有时候看起来「智能」的设计，实际上可能是不必要的开销。随着模型能力提升，很多之前的脚手架变得不必要了。

Agent 需要专门训练的模型吗？

这是一个经常被问到的问题：我们是不是应该为特定的 Agent 任务训练或微调一个专门的模型？这个问题很有意思，因为它涉及到对 Agent 本质的理解。

比如说 Deep Research 这样一个经典的 Agent 实践案例。OpenAI 推出了专用于 Deep Research 的模型，这是一个专门为研究任务优化的模型。但有趣的是，从实际使用效果来看，它目前的表现并不如最新的旗舰模型好。很多时候，我发现直接使用 GPT-5-Thinking 通过连续工具调用来完成研究任务，效果反而更好，响应也更灵活。这说明什么？说明为特定任务训练模型并不总是最优解。

另一个案例是阿里巴巴的 DeepResearch 项目。他们采取了一个系统化的训练路径，提出了一个四阶段的训练范式：先构建高质量的浏览数据，然后采样轨迹，接着用监督微调来实现冷启动，最后通过强化学习来提升泛化能力。他们基于 ReAct 框架实现了这个 web agent，在 GAIA 和 WebWalkerQA 这两个信息搜索基准上取得了不错的成绩。

它展示了如何系统地构建训练数据和设计训练流程。但有趣的是，论文中的对比实验显示，OpenAI 的 Deep Research 通过端到端强化学习训练取得了更高的分数。这说明端到端训练确实有潜力，但也揭示了一个关键问题：这种方法需要大量的计算资源、精心设计的训练数据和复杂的训练流程。对于大多数团队来说，这个门槛是相当高的。

更重要的是，WebDancer 论文还发现，那些基于原生强推理模型（比如 QwQ-32B）构建的 agentic 系统，在没有专门训练的情况下也能取得相当不错的效果。这让我思考一个问题：对于大多数实际应用场景，我们真的需要训练专门的模型吗？还是说，通过更好的系统设计、提示词工程和工作流优化，就能用现有的通用模型达到类似甚至更好的效果？

我个人倾向于后者。WebDancer 和 Deep Research 这类端到端训练的 Agent 代表了一个重要的研究方向，但对于实际应用来说，用好现有的通用模型往往是更实用的选择。除非你有充分的资源和明确的场景需求，否则通过优化系统设计、改进提示词、调整工作流来提升效果，通常是更经济、更灵活的路径。而且这种方式的迭代速度要快得多，你可以根据实际反馈快速调整，而不需要每次都重新训练模型。

我的看法是，对于大多数场景，用好现有的通用模型，加上合理的提示词工程和系统设计，往往比训练专门模型更实用。通用模型的优势在于它们的泛化能力和灵活性。当你用 GPT-5 或 Claude 4.5 Sonnet 这样的模型时，你可以通过调整提示词、改变工具配置、修改工作流来快速迭代。如果某个环节表现不好，你可以马上调整。而如果你训练了专门的模型，这种灵活性就大打折扣了。

当然，这不是说专门训练永远没有价值。如果你有非常明确的、高度重复的任务，有大量的标注数据，而且通用模型在这个任务上表现确实不够好，那么训练专门模型可能是值得的。而且这里有一个很重要但经常被忽视的考量：推理成本。

假设你的业务每天需要处理几百万次 Agent 调用，如果每次都用 GPT-5 或 Claude 4.5 Sonnet 这样的旗舰模型，推理成本会非常高。这时候如果你有能力训练一个更小但在你的特定业务领域更加专业的模型，推理成本的节省可能是相当可观的。

假设你做的是电商客服 Agent，主要处理订单查询、退换货、物流跟踪这些标准化的任务。一个 70B 参数的通用模型可能可以完全胜任，但如果你训练一个 7B 或者 13B 的领域专用模型，专门针对你的业务场景和知识库进行优化，它在这些特定任务上的表现可能不输大模型，但推理成本可能只有十分之一甚至更低。当你的日调用量是十万次、百万次的时候，这个成本差异就非常显著了。

但是但是，训练和维护专门模型有前期成本：数据标注、模型训练、持续优化、版本管理等等。但如果你的业务规模足够大，这些前期投入可以通过推理成本的持续节省来摊销。反过来说，如果你的业务还在早期，调用量不大，或者任务类型经常变化，那么前期投入可能永远收不回来。

还有一个考虑是响应速度。更小的模型通常推理速度更快，延迟更低。对于需要实时交互的场景，比如语音客服、即时聊天，这种速度优势可能比成本优势更重要。用户等待半秒和等待两秒，体验差异是巨大的。

但需要强调的是，这个选择高度依赖你的具体情况。你需要考虑你的业务规模有多大？任务的标准化程度如何？你有没有足够的训练数据和技术能力？模型需要多久更新一次？这些问题的答案会决定训练专门模型是不是一个明智的投资。

对于大多数 Agent 应用来说，我还是觉得先把通用模型用好。当你发现推理成本确实成为一个显著的瓶颈，或者你的任务足够标准化、业务规模足够大的时候，再考虑训练专门模型。这时候你已经有了充分的业务数据和清晰的需求理解，训练出来的模型会更有针对性，投资回报也更明确。

产品经理与 AI 原型

说到这里，我想谈谈 OpenAI AgentKit 里的 Agent Builder 和 ChatKit 这些工具。当我看到这些工具时，我的第一反应是：这对产品经理来说太重要了。但这个重要性不是说产品经理「也可以做技术活」了，而是因为 AI 产品，特别是基于 LLMs API 的套壳产品（0.0），有一个本质特点：你必须真正体验整个流程，才能理解它到底怎么工作的。

传统产品开发中，产品经理可以通过画原型图、写文档、描述流程来传达想法。你画一个登录页面，一个数据展示页，写清楚交互逻辑，开发照着实现就行。但 AI 产品不是这样的。当你在纸上画一个「AI 分析数据」的流程框时，你可能觉得很清楚：输入数据，AI 处理，输出结果。但实际上，AI 会怎么处理？它会先做什么，后做什么？遇到模糊指令会怎么反应？什么时候会调用哪个工具？中间会产生什么样的中间结果？这些都不是你在纸上能想清楚的。

这里有一个更深层的变化，关于产品设计流程本身。在传统产品开发中，流程通常是：先做用户研究，然后画交互设计稿，接着做视觉设计，最后才是开发实现。这个流程的前提是，我们能够预先设计好产品的行为。按钮点击后会发生什么，表单提交后显示什么，这些都是确定的、可预测的。

但在 AI 产品中，这个流程需要部分颠倒。你不能先画一套完整的交互设计稿，然后期望 AI 完全按照设计稿的预期来表现。因为 AI 的行为本身就是不确定的，它是产品体验的核心组成部分。你需要先搭建一个可运行的原型，让 AI 实际跑起来，观察它在不同输入下的表现，然后基于这些观察来设计交互。

让我用一个具体例子来说明。比如说，你想让 AI 帮用户做市场研究。在原型图上你可能画一个搜索框，一个结果展示区，看起来很简单。但实际上，AI 收到用户的研究需求后，它应该先分解任务还是直接搜索？搜索到的信息如何筛选和组织？什么时候生成中间报告？什么时候需要深入某个细节？这些决策点都会显著影响用户体验。

如果 AI 一上来就给用户展示十几条搜索结果，用户可能会觉得太乱；如果 AI 埋头研究十分钟才给反馈，用户可能会觉得太慢。更复杂的是，AI 实际分析时的步骤是动态的。有时候它需要三步，有时候需要十步。有时候它会先清洗数据，有时候会直接分析。有时候它发现信息不足需要向用户提问，有时候它可以直接给出结论。这些行为模式，你在画原型图的时候是预测不到的。如果你先定义了一个固定的交互流程，然后让 AI 去适配这个流程，结果往往是别扭的、不自然的。

正确的做法是什么呢？先搭建一个最简单的原型，让 AI 实际处理一些典型的研究任务。你会发现它有哪些常见的行为模式，它在什么情况下需要和用户交互，它产生的中间结果有什么特点，它容易在哪些环节卡住。基于这些真实的观察，你才能设计出符合 AI 实际行为特点的交互界面。这些问题，你只有真正搭建一个可以运行的流程，让 AI 实际执行一遍，才能发现。

这不是说交互设计不重要了，恰恰相反，交互设计在 AI 产品中更重要。但它的时机变了。你需要先让 AI 跑起来，理解它的行为特点，然后再设计如何把这些行为以最好的方式呈现给用户。这就像拍纪录片和拍故事片的区别。故事片是先写好剧本再拍摄，纪录片是先拍摄素材再剪辑成片。AI 产品的设计更像拍纪录片，你需要先观察「演员」（AI）的真实表现，然后再决定如何剪辑和呈现。

这不是在提倡技术至上，让产品经理都去学编程。而是说，AI 产品的特殊性要求产品经理必须有能力通过这些工具快速制作可运行的原型。你需要真听、真看、真感受 AI 是怎么工作的，而不是基于想象来设计产品。这和传统产品设计有本质区别。传统产品的行为是确定的，点击按钮会发生什么，填写表单会得到什么反馈，这些都是可以预先设计好的。但 AI 的行为有很大的不确定性，它的决策路径、中间步骤、最终输出都可能随着输入的细微变化而改变。

这就是为什么我认为 Agent Builder 和 ChatKit 这类工具非常重要（Dify、N8N 等等）。它们降低了制作可运行原型的门槛，让产品经理可以快速搭建一个实际的工作流，看看 AI 真正的表现如何。你可以在几个小时内迭代多个版本，每次都能实际体验效果，而不是花几天时间写文档，然后等开发实现了才发现不对。

而且，这不只是关于效率，更是关于理解。这种流程的改变对产品经理意味着什么？意味着你需要更早地参与到技术实现中，而不是等到「设计完成」再交给开发。你需要和 AI 一起工作一段时间，真正理解它的能力边界和行为特点。当你自己搭建过一个 Agent 流程，看着它一步步执行任务，你会对 AI 的能力边界有更清晰的认知。你会知道哪些任务 AI 能做得很好，哪些任务它会卡壳。你会知道什么样的提示词能让 AI 理解你的意图，什么样的提示词会让它困惑。这种第一手的认知，是读再多文档也换不来的。

我的建议是，如果你是产品经理，花一些时间学习使用这些工具。不是为了替代开发，而是为了更好地理解你设计的产品到底会怎么运行。这会显著提升你的产品判断力，让你在做决策时更有底气。

评估体系：不只看结果，更要看过程

解决了上下文管理和工具设计的问题后，第三个大挑战是评估。做过 AI 产品的人都会面临一个很现实的问题：怎么判断做得好不好？

OpenAI 在推 AgentKit 时特别强调了一个功能：追踪评分（Trace Grading）。我注意到这个功能的时候，第一反应是「终于有人重视这个了」。因为这正是我在实践中逐渐意识到的一个关键问题。我把这种评估方式称为「轨迹评估」——不只看最终结果，更要看 Agent 的完整执行过程。

OpenAI 提到的一个观点我很认同：传统评估只关注能不能做到，但对于复杂的 Agent 任务，更重要的是理解为什么做到或做不到，具体是哪个环节出了问题。想象一下，你有一个包含五个步骤的 Agent：搜索信息、分析数据、调用 API、生成报告、发送通知。传统的评估只会告诉你最终结果是否正确。但追踪评分会检查每一步的执行情况，告诉你具体是哪个环节出了问题。是搜索的关键词不对？还是分析数据时出现了逻辑错误？又或者是 API 调用失败了？这种细粒度的评估对改进 Agent 至关重要。

轨迹评估：理解 Agent 的思考过程

让我详细谈谈为什么轨迹评估这么重要。我记得有一次，让 AI 研究一个技术趋势。它给出的结论看起来很合理，数据也有引用，参考文献列得很全。如果我只看最终报告，可能觉得还不错，可以交差了。但当我仔细看它的执行过程时，我发现了一个严重的问题：它其实只搜索了两三个来源，然后就匆忙下结论了。

这就像一个学生交作业，论文写得漂漂亮亮，格式也规范，但仔细一看发现他只查了两本书，其他全是自己编的。这份作业的质量显然是不够的，但如果老师只看最终论文，可能还会给个不错的分数。这个经历让我意识到，评估 Agent 不能只看结果，还要看过程。就像评价一个学生，你不能只看他的答案对不对，还要看他是怎么得出这个答案的，他的推理过程是否严密，他的研究方法是否合理。

轨迹评估就是关注 Agent 的完整执行过程。我开始记录和分析 Agent 的每一步：它搜索了哪些关键词？访问了哪些来源？在每个来源上花了多长时间？它是如何组织信息的？什么时候做出了关键决策？通过分析这些轨迹，我才能真正理解 Agent 的工作质量。

让我用一个更具体的例子来说明轨迹评估的价值。假设你问 Agent 一个问题：「中国金融未来的发展趋势，未来哪一个细分领域（例如投行、PE、固收等）更有上升空间？」这是一个复杂的研究问题，涉及多个维度。

首先，Agent 需要意识到这个问题本身就有歧义。「上升空间」是指什么？是指市场规模的增长潜力？还是从业者的职业发展机会？又或者是投资回报率的提升？不同的理解会导致完全不同的研究方向。一个聪明的 Agent 应该在开始深入研究前，先向用户发起问题澄清或者合理推断这个核心概念。通过轨迹评估，你可以看到 Agent 是否考虑了这个问题，它是如何处理这种歧义的。

当 Agent 开始搜索时，它很快会遇到第一个挑战：信息的时效性问题。如果找到一篇 2023 年的报告说「科技投行业务增长迅猛」，它需要判断这个趋势在 2025 年是否依然有效。中国金融市场变化很快，政策环境、市场情绪、国际关系都可能在短期内发生重大转变。Agent 必须学会优先使用最新的数据，同时又不能完全忽视历史趋势。通过轨迹评估，你可以看到 Agent 搜索的时间分布，它是否关注了信息的时效性。

更棘手的是，Agent 很可能会发现不同来源给出的答案相互矛盾。有的报告说 PE 市场前景广阔，有的说监管收紧会限制发展。有的专家看好固收业务，有的认为投行更有机会。面对这些冲突，Agent 不能简单地选择相信其中一个，它必须自行评估和理解这些观点背后的逻辑。通过轨迹评估，你可以看到 Agent 是否意识到了这些矛盾，它是如何处理的，是简单地罗列不同观点，还是做了深入的分析和综合。

在研究过程中，Agent 可能还会遇到意外的发现，而这些发现可能需要调整研究方向。比如它可能发现，中国正在大力发展绿色金融，这可能是一个重要的趋势，但最初的问题没有明确提到。一个好的 Agent 应该能够灵活调整，将这个新发现纳入研究范围。通过轨迹评估，你可以看到 Agent 的研究路径是否灵活，它是否能够根据新信息调整策略。

在某个时刻，Agent 可能会意识到，它需要找到一个分析框架。它不能简单地罗列每个领域的情况，而是需要建立一个系统的评估标准。也许应该从监管政策的方向来看？中国金融监管在收紧还是放松，哪些业务受到鼓励，哪些受到限制？或者从市场需求的角度？中国经济转型需要什么样的金融服务，哪种业态最匹配这个需求？又或者从国际比较的视角？成熟市场的金融结构能给中国提供什么启示？每选择一个框架，研究的路径就会大不相同。通过轨迹评估，你可以看到 Agent 是否建立了分析框架，这个框架是否合理。

你看，如果采用传统的静态评估方式，我们只会检查 Agent 最终给出的答案，这个答案可能是对的，但我们完全看不到它是如何得出这个结论的。它是经过深思熟虑权衡多个因素后的判断，还是只是简单地摘取了第一个看到的观点？它考虑了不同的分析框架吗？它处理了相互矛盾的信息吗？它意识到问题的复杂性和不确定性了吗？这些问题，只有通过轨迹评估才能回答。

多维度评估体系：Manus 的经验

Manus 的团队分享他们的评估体系：他们一开始使用的是像 GAIA 这样的学术基准测试，但发现在这些基准上得高分的模型，用户在实际使用 Manus 时反而不喜欢。他们用「super misaligned」（严重不匹配）这个词来形容这种情况。

问题在哪里呢？学术基准通常关注的是「能不能做到」，比如能否正确回答一个需要五步推理的问题。但真实用户关心的还包括很多其他维度，比如 Agent 的响应速度够不够快，它的解释够不够清楚，它生成的代码风格是否符合用户习惯，它创建的可视化图表是否美观易读，它在遇到模糊指令时能否聪明地理解用户意图。学术基准中的任务往往有标准答案，你可以用准确率来衡量。但很多真实任务是开放式的，没有唯一正确答案。

所以 Manus 团队建立了一个三层评估体系。最核心的一层是用户评分系统，每当一个任务完成，他们会请求用户给出评价，这是「金标准」，因为它直接反映了用户的真实满意度。第二层是内部的自动化测试，但他们不再依赖公开的学术基准，而是创建了自己的数据集，这些数据集有清晰的、可验证的答案，特别强调要测试「执行性任务」而不是「推理性任务」，因为 Agent 的价值不只是思考，更重要的是行动。第三层是大量的人工评估，因为有些东西本质上就是主观的，无法用算法来判断，比如网站生成和数据可视化的美观性。

这其实说明评估 Agent 需要多个维度的综合考量，既要有客观的指标，也要有主观的判断；既要看最终结果，也要看执行过程；既要有自动化测试，也要有人工评估。没有一个单一的指标能完全衡量 Agent 的质量。

一些实践原则

第一个是简单往往更好。我发现很多时候，简化系统反而能带来更好的效果。比如我曾经尝试过让 Agent 自己做很详细的任务规划，列出每一步要做什么，预期结果是什么。听起来很完美对吧？但实际上这个规划过程本身就消耗了大量的 tokens 和时间，而且规划往往跟不上变化。后来我简化了这个过程，只让 Agent 确定大的方向，具体步骤则在后续执行过程中动态决定。结果反而差不多，但是 tokens 消耗大幅度降低了。不要限制 AI 的能力，而是给它更清晰的方向，让它把精力花在真正重要的事情上。

第二个是持续跟踪很关键。我会记录每次任务的执行时间、token 消耗、调用了哪些工具、产生了什么结果。这样能发现很多隐藏的问题，比如某个工具调用消耗很差，非常不适合 AI 使用，需要整体进行调整。又比如我发现某类任务的效果也特别差，我开始逐步分析 AI 的轨迹，甚至逐步阅读它们的思考内容，才发现是提示词设计有问题，有一大块内容 AI 理解有歧义。

第三个是理解场景比掌握技术更重要，技术选择都是为场景服务的，比如说前文提到的检索，在不同场景下最优方案可能完全不同。只有深刻理解用户要做什么，你才能做出正确的设计决策。不要被技术的炫酷所迷惑，始终问自己：这个技术真的适合我的场景吗？

第四个是避免过度工程，这是 Manus 团队那里分享的。他们说最大的进步来自简化和删除不必要的技巧，而不是增加更复杂的管理层。确实，有时候你会觉得加一个新功能、加一个新监控、加一个新优化能解决问题，但实际上可能让系统更复杂，维护成本更高。

真正的改进往往来自于删除冗余，简化架构和流程。随着模型能力不断提升，很多之前看起来必要的辅助做法，实际上已经不需要了，要敢于删除，敢于简化。

一些思考和展望

怎么做一个好的 AI Agent 这不是一个技术问题，它涉及到系统设计、产品思维、用户体验等多个维度。当你需要管理复杂的上下文，设计合理的工具接口，建立有效的评估体系时，你会发现每个决策都是一个权衡的过程。没有完美的方案，只有适合特定场景的方案。

OpenAI 发布 AgentKit，Anthropic 分享自己基于 Multi Agents 的 Research 经验，Manus 的 Agent 构建经验，这些都说明整个行业正在从「能不能做」转向「怎么做得更好」。

总体来说，

上下文管理的重要性怎么强调都不为过。我在实践中深刻体会到，这不是一个可以事后优化的问题，而是从一开始就要认真考虑的核心设计。你采用什么样的架构思路，如何组织信息流，选择什么样的检索方式，这些决策会深刻影响系统的性能和可扩展性。

工具设计也是如此，在满足需求的情况下，给予最大的灵活性，非常重要。同时工具本身的输出质量也是重中之重。

评估体系的建立需要时间和耐心，不要期望一开始就有完美的评估方案，而是要在实践中不断调整。轨迹评估是一个很有价值的补充，它让我们不只关注结果，也关注过程。这对理解 Agent 的行为和改进系统至关重要。

产品经理对 AI 产品的参与方式也在发生变化。不是说产品经理要变成工程师，而是说他们需要有能力快速制作可运行的原型，真正体验 AI 的行为。Dify、N8N、Agent Builder 这类工具降低了这个门槛，让产品经理可以更深入地参与到产品设计中，这是一个积极的趋势。

随着模型能力不断提升，很多今天看起来复杂的问题可能会变得简单。我们现在花大力气解决的上下文管理问题，也许未来的模型能更好地处理。但我相信，深刻理解用户需求，做出合理的设计权衡，持续优化，这些核心能力会一直重要。技术在变，但好产品的本质不会变。