构建Agent系统
标题：构建智能体系统
在Airtree，我们正在构建智能体以自动化投资流程中的部分环节。公司研究、会议准备、交易分析、常规尽职调查文件整理。这类知识工作通常占据风险投资人一周中的大部分时间。我们已进行了大约三个月，目前面临的决策与每个正在构建智能体产品的团队当前所面临的问题如出一辙。
本文正是关于这些决策。如果你今天正在为知识工作设计一个AI智能体系统，你应该首先提出哪些问题，有哪些选项可供选择，以及你将面临哪些权衡。
你真的需要智能体吗？
Anthropic基于与数十个团队合作经验编写的《构建有效智能体》指南，开篇就提出了警告：寻找尽可能简单的解决方案，仅在需要时增加复杂性，这可能意味着根本不需要构建智能体系统。如果我只是想总结一篇研究论文，我不需要一个智能体。当任务需要分支或迭代时，智能体才真正体现出其价值。我们的公司研究工作流程就需要一个智能体：它需要搜索多个数据源，根据发现决定追踪哪些线索，在初步结果不足时循环回溯，并综合多个来源的信息。
十二个月间的变化
一年前，编排决策主要围绕框架选择。是选LangGraph还是CrewAI？AutoGen还是定制方案？团队会花费数周评估选项并争论架构设计。
如今，这场争论在很大程度上已自行解决。各框架提供的功能越来越重叠。LangGraph提供细粒度的状态管理。CrewAI适合类似团队的协调工作。选择适合你技术栈的那个，然后继续推进。我们从所有可信来源读到的实践共识是一致的：一个带有ReAct循环和精心选择工具的单一智能体，就能处理大多数现实世界的任务。只有在有明确证据表明单个智能体无法满足你的质量标准时，才增加多智能体的复杂性。
但更大的变化发生在框架之下：协议层。Anthropic的模型上下文协议已成为连接智能体与工具和数据的标准。OpenAI和Google都采用了它，每个主要的编码工具都支持它。MCP、OpenAI的AGENTS.md约定（已在60,000多个代码库中使用）、Google的Agent-to-Agent协议以及Block的goose，已于2025年12月捐赠给了Linux基金会旗下新成立的Agentic AI基金会。协议层正在开放治理下趋于统一。一年前，将智能体连接到新数据源意味着编写自定义集成代码。现在，你只需要寻找一个MCP服务器。
团队现在也将架构视为产品决策，而不仅仅是技术决策。Anthropic、Google和Microsoft都发布了惊人相似的模式分类法。正确的模式完全取决于你的任务结构。一个”计划与执行分离”的模式，即由能力强的模型制定计划，由成本更低的模型执行步骤，可以将成本降低一个数量级。一个将简单查询分发给快速模型、将复杂查询升级处理的”路由器”，可以在不牺牲难题解决质量的前提下保持平均成本低廉。这些是伪装成架构决策的产品决策，并且它们会产生复合效应。错误的模式可能使一个原本盈利的产品在规模化时变得不经济。
上下文是真正的工程难题
构建我们系统最困难的部分不是选择框架或模式，而是上下文管理。
Anthropic的多智能体研究系统发现，令牌使用量解释了80%的性能差异。这是为一个信息检索系统得出的单一发现，在该系统中，搜索广度自然会驱动结果。对于瓶颈在于推理质量或多步骤规划的任务，模型能力仍然占主导地位。但对于我们的用例——跨数据源进行综合的研究智能体——这与我们的体验相符。当我们专注于精心策划进入上下文窗口的内容，而不是尝试不同模型时，我们的智能体性能得到了显著提升。
在这方面做得好的生产团队采用了一种称为”渐进式披露”的模式，让智能体逐步发现上下文，而不是一次性接收所有信息。Cursor的动态上下文发现（工具输出和定义按需加载）将令牌使用量减少了46.9%。Vercel删除了其智能体80%的工具，观察到其最差情况的查询从724秒内执行100步失败，变为141秒内执行19步完成。他们一开始就拥有太多工具，而这正是问题的一部分。通过移除而非添加上下文带来的改进是惊人的。
模型能力使得简单的脚手架变得可行，但在该能力范围内，脚手架决定了产品是否有效。Manus自推出以来已经重写了四次其智能体框架，每次重写都侧重于更精确地塑造上下文。他们的启发式方法很好：如果你的脚手架随着模型变好而变得越来越复杂，那一定有问题。
如何知道它在正常工作？
这是大多数团队（包括我们）投入不足的地方。
一个编码智能体可以运行测试。一个客户支持智能体可以衡量解决率。但是，你如何评估一个研究智能体的综合报告是否真的好？它是否找到了正确的来源？是否遗漏了重要信息？
我们还没有解决这个问题。我们正在探索的是自动化检查和定期人工抽样审查输出结果的结合。自动化检查捕捉机械性故障：智能体是否使用了它应该使用的数据源，是否调用了正确的API，输出结构是否正确。人工审查则捕捉自动化检查无法发现的质性问题。两者单独使用都不够。
人机回环设计可以说是整个系统中最难的产品问题。LangChain的调查（偏向于AI前沿团队）中，89%的受访者已经建立了可观测性。OpenTelemetry的GenAI语义约定正在成为检测的标准。但可观测性告诉你发生了什么。设计问题在于，什么应该触发人工干预，以及这种干预体验感觉如何。
Stripe在合并前审查每一个AI生成的拉取请求。这对代码有效，因为审查是异步的，且错误合并的成本很高。但这不适用于需要智能体实时操作的工作流。我们仍在研究针对不同工作流，我们的审查节点应该设置在哪里。智能体应该在何时将发现呈现给人类投资者评估，又可以在何时自行行动？正确的干预率取决于你所在领域错误的成本。对于客户服务路由，顶尖团队的升级率是个位数。对于投资研究，我们有意让人保持在循环中。正确设置触发条件是产品工艺，而非工程问题。
我们仍在探索的问题
诚实的回答是，我们仍处于早期阶段。我们的研究智能体大约在三分钟内生成一份公司简报，而过去这需要分析师几个小时。但系统还很粗糙，我们还不能自信地量化完整的投资回报率。上下文工程比我们预期的更难，工具也滞后于需求。理解你的智能体在每个步骤看到了什么，以及它为何做出那样的决策，需要自定义检测工具，而我们尚未找到适合知识工作的优秀框架。
安全是另一个维度。访问内部数据、进行API调用并代表用户执行操作的智能体引入了需要管理的风险。模型在不断改进。Stripe的一次性”小助手”每周生成超过1300个拉取请求，无需多轮推理，这在两年前是不可能的。随着模型改进，更简单的模式开始处理更难的问题。你今天设计的系统可能在六个月内需要更少的脚手架。
我们认为，为知识工作设计AI智能体系统是2026年最重要的产品问题之一。框架层正在商品化。协议层正在标准化。尚未商品化的是特定领域的上下文工程以及人机协作的产品设计。Claude Cowork是解决该问题的第一步，但它仍然很初级。构建我们自己系统的经验教训，被证明比我们做过的任何”理论开发”都更有用。如果你正在这个领域进行构建，或者你已经找到了评估知识工作智能体的方法，我们很乐意了解。
感谢阅读Jax的《建立连接》！免费订阅以接收新文章。
订阅
分享
上一篇
原文来源：Jax (Airtree)
