这是一篇很干的干货,也是我最近对 Agent 的一些思考。
一、现阶段企业级 Agent 的实现及弊端
目前我正在开发一款 AI Sales Agent,它是基于 langgraph 、langchain 构建,在现有的架构设计上,我们采取了一种较为简洁的实现方式:LLM + Tool 的模式。它最大的好处就是 langgraph 的链路非常简单,不会出现多个分支的情况,LLM 会根据上下文自行判断是否需要调用 tool,不需要的话则直接返回。
在项目代码中定义了好几个 tool,比如数据格式校验、提取信息、设置表单等等,每一个 tool 的功能非常单一,但是也存在一个明显的问题,有的 tool 是存在依赖关系,虽然在 prompt 里明确约束了,但 LLM 并不会一直如你所愿的执行,所以在产品端会偶现不是期望的功能。另外一个问题是随着 tool 越来越多上下文管理变得十分困难,会出现聊天工具记忆丢失的情况。
总体来说,上下文窗口占用过多会加剧第一个问题出现的频率,所以如何管理上下文才是当下 Agent 开发的核心难点。
二、解决方案 — 使用 MCP 执行代码
它是由 Claude code 的母公司 Anthropic 提出,一旦你理解了 Anthropic 的解决方案,它就会很简单。
随着代码执行环境对于 Agent 来说变得越来越普遍,解决方案是将 MCP 服务器呈现为代码 API,而不是直接工具调用。
Agent 编写代码与 MCP 服务器交互。
这种方法解决了这两个挑战:Agent 只能加载他们需要的工具,并在将结果传递回模型之前在执行环境中处理数据。
主要区别如下:
目前的做法:Agent 使用工具调用API→模型加载所有工具定义→模型直接调用工具→结果通过上下文返回。
代码执行方式:Agent编写代码→代码仅导入需要的工具→代码执行并处理数据→仅最终结果返回模型。
你的 MCP 服务器成为代码 API。无需将工具注册为模型直接调用的函数调用,而是将它们呈现为 Agent 可以以编程方式导入和使用的模块。
三、它在实践中是如何运作的
需求:假设你的 Agent 需要搜索 Salesforce 记录、筛选结果并创建摘要。
目前做法
按照我们现有的设计大概是这样一个链路设计:
- 将所有 Salesforce 工具定义加载到上下文中
- Agent 调用搜索工具
- 完整结果通过上下文返回(可能有几十上百个结果)
- Agent 调用过滤工具
- Agent 获得上下文过滤结果
- Agent 调用汇总工具
- 返回总结结果给到 LLM
- LLM 输出最后的结果
代码如下:
# Traditional approach - each step is a separate tool call# Step 1: Search (tool call 1)search_results = agent.call_tool("search_salesforce", { "query": "active accounts", "fields": ["name", "revenue", "status"]})# Returns 1000 records, all flow through context# Step 2: Filter (tool call 2) filtered_results = agent.call_tool("filter_records", { "data": search_results, # Passing large dataset through context "condition": "revenue > 1000000"})# Filtered data flows back through context# Step 3: Summarize (tool call 3)summary = agent.call_tool("create_summary", { "data": filtered_results # More data through context})# Total: 3 separate tool calls, all intermediate data through context
改进方案
代码执行方式:
- Agent 编写导入 Salesforce 模块的代码
- 代码在一次执行中搜索、过滤和汇总
- 仅最终摘要返回给代理(可能是 500 个token)
以下是代理通过代码执行编写的内容:
// Code execution approach - single execution, all processing in environmentimport { salesforce } from 'mcp-servers';// Everything happens in the execution environmentasync function getSalesforceSummary() { // Search const results = await salesforce.search({ query: "active accounts", fields: ["name", "revenue", "status"] }); // 1000 records - but they never touch the model's context // Filter (happens right here in code) const filtered = results.filter(record => record.revenue > 1000000); // Filtered to 50 records - still in execution environment // Summarize (still in code) const summary = { total_accounts: filtered.length, total_revenue: filtered.reduce((sum, r) => sum + r.revenue, 0), top_account: filtered.sort((a, b) => b.revenue - a.revenue)[0] }; return summary; // Only this small object goes back to the model}// Agent gets back just the summary - maybe 100 tokens
中间数据永远不会触及模型的上下文。这一切都发生在代码执行环境中。
当 Anthropic 测试这种方法时,之前消耗 150,000 个 token 的工作流程减少到 2,000 个 token。
token 节省并不是唯一的好处;由于执行代码而不是工具调用,因此一切运行得更快。
Agent 可以通过本机代码构造使用循环、条件和错误处理,而不是进行顺序 API 调用。
四、实现代码执行的成本与收益
这种方法增加了复杂性,因为现在需要一个具有适当沙箱、资源限制和监控的安全代码执行环境,而直接工具调用不需要这些。
但对于需要可扩展的 Agent 来说,其好处远远超过了开发成本。
它可以获得更便宜的操作、更快的响应,并且能够将 Agent 连接到数百种工具而无需达到上下文限制。
方案的 7 个主要优点:
1.大量节省 token
将工作流程从 150,000 个 token 减少到 2,000 个 token 意味着 API 成本下降了 98% 以上。
2.渐进式工具发现
Agent 可以浏览可用工具、搜索特定功能或仅在需要时阅读文档。它不需要在开始工作之前记住整个工具目录。
3. 中间数据处理
Agent 可以在代码执行环境中过滤、转换和聚合数据,然后再到达 LLM。
4. 更好的流程控制
编写代码使 Agent 能够访问正确的编程结构。这减少了延迟和 token 消耗。Agent 无需编写 50 个单独的工具调用和 50 个模型往返调用,而是编写在单次执行中处理所有 50 个操作的代码。
5. 隐私保护
敏感数据可以在您的工作流程中流动,而无需进入模型的上下文。只有显式记录或返回的值才对模型可见。其他一切都保留在执行环境中。您可以处理机密信息,据此做出决策,并仅返回最终结果。
6. 状态持久化
Agent 可以将中间结果保存到文件中并稍后恢复工作。
这使得跨多个会话的长时间运行任务成为可能。Agent 不需要将所有内容都放在上下文中或每次都从头开始。它可以检查进度、保存状态并从中断处继续。
7. 可重复使用的技能
随着时间的推移,你将构建一个更高级别的功能库。需要多个步骤的复杂操作变成单个函数调用。随着这些技能的发展,你的 Agent 会变得更加有能力。
“Anthropic 甚至建议使用 SKILL.MD 文件记录这些内容,以便 Agent 可以参考其自己以前的工作。”
最后的想法
这种方法改变了构建 Agent 的成本,使得 Agent 更加高效和聪明。
当构建需要以下功能的代理时,使用 MCP 执行代码很有意义:
1. 访问许多工具
如果 Agent 连接到数十个服务,那么这种方法就变得至关重要。传统方法在规模化时就失效了。
2.复杂的工作流程
具有数据转换、过滤和聚合的多步骤流程从环境内处理中获益匪浅。
3.长时间运行的任务
任何需要状态持久性或跨越多个会话的内容都可以更好地与代码执行配合。
如何学习大模型 AI ?
由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段(10天):初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么?
- 大模型是怎样获得「智能」的?
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例:向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段(30天):高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示(Embeddings)
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段(30天):模型训练
恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。
到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2:手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段(20天):商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例:如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。
如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。
这份完整版的大模型 AI 学习资料已经上传优快云,朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】


1724

被折叠的 条评论
为什么被折叠?



