AI Agent

去年这个时候,团队里讨论得最多的还是"这句 system prompt 该怎么措辞"。有人为了一个 Agent 不肯老老实实调用工具,把 prompt 改了三十多版,加感叹号、加大写、加"这非常重要"——最后发现真正起作用的,是把那个工具的描述从一坨 200 行的 JSON Schema 砍到 40 行。 prompt 没救活它,砍上下文救活了它。 这件事在 2026 年已经不是个例。Chroma 在 2025 年做过一组实验,测了 18 个当时最强的模型,结论很扎心:每一个模型,输入一长,准确率都会掉。有的模型能在 95% 稳住一阵,然后一旦输入越过某个长度,直接跳水到 60%。模型不是线性变笨的,是到了某个点"塌方"。 所以 2026 年大家嘴里挂着的词,从 prompt engineering 变成了 context engineering(上下文工程)。这不是换个时髦说法。它是承认了一件事:模型每一次推理,看到的是整个上下文窗口,而不只是你那段精心打磨的 prompt。 窗口里还有工具定义、历史对话、检索回来的文档、记忆、上一步工具吐出来的一大坨结果——这些东西你不管,它们就替你"管"了模型。 prompt engineering 没死,它只是被降格了 先把关系说清楚,免得误会。 context engineering 不是来取代 prompt engineering 的。Anthropic 在那篇《Effective context engineering for AI agents》里说得很直接:prompt engineering 是 context engineering 的一个子集。 写好一段指令,依然重要;只是它现在只是你要操心的众多东西里的一个。 两者问的问题不一样: prompt engineering 问的是:“这句话我该怎么措辞?” context engineering 问的是:“模型这一刻,到底需要看到哪些信息?” 一次性的任务——翻译一段话、改写一封邮件——prompt engineering 基本够用。但只要你做的是 Agent,是那种要跑很多轮、要调工具、要记住前面发生过什么的系统,问题立刻就变了。你面对的不再是"一段 prompt",而是一个随着每一步在不断变化的上下文状态。这个状态怎么攒、怎么裁、怎么压,就是 context engineering。 ...

我见过一个团队为了让 Agent “更聪明”,把模型从中杯换成大杯,账单翻了三倍,效果几乎没动。后来定位下来,问题出在一个叫 query 的工具上:它的描述只有一句"查询数据库",返回的是一坨 4000 行的 JSON,里面塞满了 created_at_unix、tenant_uuid、row_version 这种字段。模型不是不聪明,是它每次调用完都得在一堆噪声里捞针,然后经常捞错。 把这个工具拆成两个、描述写清楚、返回值砍掉八成,中杯模型的表现就超过了原来大杯的版本。 这不是个例。Agent 能力的天花板,很多时候是工具设计,不是模型。 模型是你换不动的那部分——它由 Anthropic、OpenAI 训练,你只能选型;工具是你完全能控制的那部分。把精力花在能控制的地方,回报率高得多。 Anthropic 在 2026 年那篇《Writing effective tools for AI agents》里有一句话我很认同:工具是一种新的软件形态,它是确定性系统和非确定性 Agent 之间的契约。你不能再按"给另一个程序员写 API"的思路写工具——调用方变了,设计原则就得跟着变。 工具描述:你在跟模型"招标" 模型面对一组工具,做的事情和招标差不多:读每个工具的描述,判断"这个活该派给谁"。描述写得含糊,它就选错;描述之间边界不清,它就来回横跳。 最常见的坏味道是用实现细节代替使用场景。 1 2 3 4 5 6 7 8 9 10 11 12 13 # 反例 { "name": "db_query", "description": "对主库执行 SQL 查询" } # 正例 { "name": "search_orders", "description": "按用户 ID、时间范围或订单状态查询订单。 用于回答'用户买过什么''某笔订单到哪了'这类问题。 不要用它查商品库存——那是 search_inventory 的活。" } 差别在哪?反例描述的是"工具内部怎么干活"(执行 SQL),模型并不关心这个;它关心的是"什么时候该用我"。正例直接给出触发场景,还顺手划清了和邻居工具的边界。 ...

用一个下午就能搭出一个像样的 Agent demo。接个大模型、写几个工具、调通 ReAct 循环,跑十条 case,全过。截图发群里,大家鼓掌。 两周后,一个客户在工单里贴出对话记录:你的 Agent 把退款金额算成了原价的三倍,还信誓旦旦地说"已为您处理"。你翻监控面板——CPU 正常、接口 P99 40ms、错误率 0.02%,一片绿。 这就是 Agent 工程里最反直觉的地方:搭出来是最简单的一步,知道它到底好不好,才是真正的工程。传统软件你写完测试、跑通 CI,基本就放心了;Agent 不行——它每次的输出都不一样,它"出错"的方式根本不会触发任何异常。这篇讲讲上线之后那部分:看什么指标、怎么评、怎么防回归。 为什么你那套监控不管用 先说清楚传统监控为什么在这里失灵。 传统软件的故障是二值的:要么 200,要么 500;要么返回了,要么超时了。你的告警系统盯着这些信号,出事就响。Agent 的故障是语义的:HTTP 200,JSON 合法,字段齐全,延迟正常——内容是错的。Agent 自信地编了一个不存在的退货政策,调了正确的工具但传错了参数,绕了七步才完成一件三步能干完的事。这些在传统监控眼里全是"成功请求"。 更麻烦的是 Agent 是非确定性的。同样一句"帮我查下上个月的账单",今天它走两步给出答案,明天可能走五步还问你要确认。你没法用"输入 X 必然输出 Y"来断言。所以 Agent 的评估,本质上是在做概率系统的质量管理——你管的不是单次对错,是一个分布。 还有一层:Agent 是多步的。一次任务里,规划器把目标拆成子步骤,工具选择器挑了几个工具,检索器拉了上下文,模型可能还重试了两次,最后才有一个回答。出了问题,你得知道是哪一步坏的。只盯着最终输出,等于只看考试总分不看错题——你知道它考砸了,但不知道为什么。 flowchart TD A[用户请求] --> B[规划拆解子任务] B --> C[工具选择] C --> D[工具调用] D --> E{结果够了吗} E -->|不够| B E -->|够了| F[生成回答] F --> G[返回用户] style B fill:#fde7c2,stroke:#e8b23c style C fill:#fde7c2,stroke:#e8b23c style D fill:#fde7c2,stroke:#e8b23c 橙色那三块——规划、选工具、调工具——是 Agent 区别于"一次 LLM 调用"的地方,也是大多数故障的发生地。你的可观测性必须能看进这三块,而不只是看进出。 ...

团队花三个月,搭了一套五个角色的多 Agent 编排:Planner、Researcher、Coder、Reviewer、Reporter,各司其职,消息总线串起来,架构图画得很漂亮。 上线后效果不理想——慢,贵,而且一出错就没人知道是哪一环错的。 后来有人把其中一个单 Agent 的 system prompt 重写了一遍,加了几个工具,效果追平了那套五角色编排。token 成本只有它的零头。 这种事我见过不止一次。2026 年,“上多 Agent"几乎成了一种默认的进步姿态——好像单 Agent 是入门,多 Agent 才是工程师该交的作业。我想把话说直白:大多数时候你并不需要多 Agent。 单 Agent 加上几个好用的工具,能解决的事比你以为的多得多。多 Agent 是一种有明确代价的架构选择,不是一次免费的升级。 先说清楚:什么是"多 Agent” 这个词被用得太松了,先收紧一下。 下面这些不是多 Agent,它们只是单 Agent 在干活: 一个 Agent 在循环里调用多个工具(查数据库、读文件、发请求); 一个 Agent 把一段固定的处理流程拆成几步顺序执行; 一个 Agent 调用一个"子任务工具"——把某个隔离的小任务丢给一次独立的 LLM 调用,拿回一段摘要。最后这个尤其重要,后面会专门讲。 真正的多 Agent,指的是多个各自带独立上下文、独立决策循环的 Agent,彼此之间要协调。它们要交接任务、传递状态、有时还要互相评审或辩论。LangGraph 的状态图、CrewAI 的"角色 crew"、AutoGen(现在叫 AG2)的多轮对话编排,做的都是这件事。 区别的关键在于:有没有"协调"这个动作。 单 Agent 调工具,工具是被动的、无状态的,调完就完;多 Agent 之间,每一个都是活的、有上下文的,它们要互相对齐。协调,就是多 Agent 全部代价的来源。 多 Agent 真正适用的三种场景 不是说多 Agent 没用。它有几个单 Agent 确实啃不动的场景,而且这几个场景的特征很清楚。 一,子任务能真正并行,而且彼此独立。 这是多 Agent 最硬的理由。Anthropic 公开过他们的多 Agent 研究系统:一个 lead agent 把一个宽泛的研究问题拆成若干互不相干的子查询,同时派出多个 subagent 各查各的,最后汇总。这里的"并行"是真并行——五个子查询之间没有依赖,谁先谁后无所谓,挂掉一个不影响其余四个。读密集型的、可扇出的活,是多 Agent 的主场。 ...

2026 年 5 月 4 日,Google 把 Project Mariner 关了。 这件事值得停下来想一秒。Mariner 是 Google 自己在 2024 年底高调推出的浏览器 Agent 原型,能同时跑 10 个任务,在 WebVoyager 这个网页任务基准上拿到 83.5%。听起来很能打。结果一年半后,它没有变成一个产品,而是被"折叠"进了 Gemini 和 Chrome 的功能里——换句话说,作为一个独立的、你可以信任它去完成任务的东西,它没活下来。 这不是 Google 一家的故事。OpenAI 也把独立的 Operator 站点下线,塞回了 ChatGPT 的 “agent mode”。整个行业在 2025 到 2026 年发生的事情,不是"浏览器 Agent 成熟了",而是"大家发现它没法单独卖,只能当一个嵌入式功能"。 那它到底能不能用?能,但你得非常清楚它能做什么、不能做什么。这篇就来拆。 先看分数:基准上的真实水平 行业里衡量电脑操作 Agent 主要看两类基准:OSWorld(完整桌面环境,操作系统级别的多步任务)和 WebVoyager / WebArena(纯网页任务)。 产品 / 模型 OSWorld(桌面) 网页任务 备注 Anthropic Claude Computer Use 72.5% — 2026 年 3 月研究预览 OpenAI CUA / Operator 32.6%–38.1% WebVoyager 87% / WebArena 58% 桌面分数有争议 Google Project Mariner — WebVoyager 83.5% 已于 5 月停为独立产品 两个事实摆在这里。 ...

你想给 Agent 加"记忆",打开教程,第一步就是:装个向量数据库,选个嵌入模型,写分块逻辑。 我见过太多团队这么干,然后卡在"为什么它检索出来的东西牛头不对马嘴"上,卡好几周。 这里有个反常识的事实:2026 年真正在干活的 Agent——Claude Code、Cursor、Devin——它们理解你的代码库,靠的是 grep、读文件树、find,不是向量库。一个能调试整个工程的 Agent 都不需要语义检索,你那个客服机器人凭什么需要? 记忆不是一个"功能",是一条演进路径。绝大多数 Agent 走到第二级、第三级就够用了一辈子。向量库是这条路的终点,不是起点——而且很多人这辈子都到不了终点,也不需要到。 这条路长什么样 flowchart TD A[对话历史窗口原始消息全塞进 prompt] -->|上下文要满了| B[摘要压缩把旧消息缩成几句话] B -->|要记的事多且结构清晰| C[结构化记忆用户画像 / 事实表键值或 SQL] C -->|要回忆的东西多又模糊| D[向量检索嵌入 + 语义搜索] style A fill:#d6f5d6,stroke:#3c9e3c style B fill:#fdf3c2,stroke:#e8c83c style C fill:#fde7c2,stroke:#e8b23c style D fill:#f5d6d6,stroke:#c23c3c 绿色那级,90% 的 Agent 起步就够用。每往下一级,复杂度都明显涨一档。升级的触发条件很具体,不是"感觉该升了"就升。 下面一级一级讲。 第一级:对话历史窗口,够用就别折腾 最朴素的记忆:把这轮对话的所有消息,原封不动塞进 prompt。用户说一句、Agent 答一句,全在上下文里。 听起来太简单了,简单到不像"记忆系统"。但你得算一笔账:2026 年主流模型的上下文窗口普遍 20 万 token 起步,长的到 100 万。一轮普通的客服对话、一次代码调试会话、一场旅行规划,撑死了几千到几万 token。整段对话原样塞进去,窗口连一半都用不满。 这一级的好处不只是简单: 零信息损失。模型看到的是逐字原文,不是被你提炼过、可能丢了关键细节的二手货。 零检索错误。没有检索这一步,就没有"该召回的没召回"“召回一堆噪音"这类问题。 零额外基础设施。不用嵌入服务,不用向量库,不用同步任务。 什么时候该往下走?只有一个信号:上下文真的要满了。 不是"对话有点长了”,是你把 token 数打出来,发现已经吃掉窗口的 60%~70%,再聊下去要溢出。在那之前,任何"我们是不是该上个记忆框架"的讨论都是过早优化。 ...

去年 12 月有件事,当时新闻没怎么吵,但回头看是个分水岭:Anthropic 把 MCP 捐给了一个叫 Agentic AI Foundation 的中立基金会,OpenAI 和 Block 是联合发起方。 翻译一下这句话的分量:MCP 不再是 Anthropic 的协议了。它从一家公司的项目,变成了像 Kubernetes、Linux 那样由基金会托管的东西。一个协议要想成为"标准",最关键的一步从来不是技术上多优雅,而是发明它的那家公司愿意放手——因为没人愿意把自己的核心管道,绑死在竞争对手的协议上。Anthropic 放了手,OpenAI 才肯全线接入。 这半年,MCP 干的事就是这一件:从一纸协议,长成一个生态。这篇不讲 MCP 是什么、怎么写一个 server——那些去年就讲过了。这篇讲的是这半年它长成了什么样,以及哪些地方还在裂。 数字先摆出来:它到底有多热 先看注册表里的 server 数量,这是最硬的指标: 时间 公开注册表 server 数 2025 Q1 末 ~1,200 2025 Q3 末 ~3,400 2025 年底 ~6,800 2026 年 4 月中 9,400+ 一年多 7.8 倍。再看采用面:到 2026 年 4 月,78% 的企业 AI 团队说自己生产环境里至少跑着一个 MCP 接入的 agent;受访 CTO 里 67% 认为 MCP 会在一年内成为他们默认的 agent 集成标准。 ...

给你的知识库问一个问题:“我们去年 Q3 的退款政策,跟今年比有什么变化?” 朴素 RAG 会怎么做?它把这一整句话拿去向量库里查一次,取回 5 个最相似的片段,塞进 prompt,让大模型生成。结果大概率是:它检索到了"今年的退款政策",但没检索到"去年 Q3 的",因为这句话作为一个整体,语义上离"今年的政策文档"更近。于是模型用今年的政策,回答了一个关于"变化"的问题——而且它不会告诉你它只看到了一半。 这就是朴素 RAG 的根本毛病。它把检索当成一个一次性的、无脑的前置步骤:查一次,查到什么算什么,然后生成。它不会判断"我查到的东西够不够",不会发现"这个问题其实要查两次",更不会在检索失败时重来。它失败的时候不会报错,会编。 2026 年,生产环境里真正能扛住复杂问题的,已经不是这条流水线了。这篇讲清楚它怎么一步步长成 Agentic RAG,以及——这是重点——多出来的延迟和成本,什么时候值,什么时候是浪费。 朴素 RAG 到底卡在哪 先把它失败的几类问题说具体,不然后面所有"改进"都是空的。 多跳问题。“写《三体》的作者还写过哪些小说?"——这要先查”《三体》的作者是谁"(刘慈欣),再用这个答案去查"刘慈欣的其他作品"。一次检索拿不到第二跳需要的关键词,因为第二跳的查询词(“刘慈欣”)根本不在原始问题里。 **模糊 / 措辞错位。**用户问"那个会自动重试的配置项叫什么",知识库里写的是"retry_policy 重试策略"。用户的口语和文档的术语对不上,向量相似度也救不回来。 问题里藏着多个子问题。“对比一下 A 方案和 B 方案的成本和上线周期”——这是四个检索意图揉在一句话里,一次检索只会取回一堆"半相关"的片段,哪个都不深。 需要计算或外部数据。“我们这个季度的获客成本环比涨了多少”——答案不在任何一个文档片段里,它需要先取两个数,再算个除法。文本检索给不了。 这些问题的共同点是:正确答案不是"检索一次就能拿到的那 5 个片段"。要么得检索多次,要么得换个查法,要么检索根本不是最后一步。朴素 RAG 的架构里没有"再来一次"这个动作,所以它只能在第一次的结果上硬生成。 演进的主线:从「流水线」到「控制循环」 把朴素 RAG 和 Agentic RAG 摆在一起看,差别不是"加了几个模块",是控制权交给了谁。 朴素 RAG 是一条固定流水线:检索 → 生成,顺序写死,模型只负责最后那步生成,没有决策权。 Agentic RAG 是一个控制循环:大模型坐在中间当指挥,它拿到问题后自己决定下一步干什么——要不要检索、检索什么、查到的东西够不够、要不要换个查询词再来一次、还是已经可以回答了。检索从"前置步骤"变成了模型手里的一个工具,跟计算器、SQL 查询、API 调用平级。 flowchart TB subgraph naive[朴素 RAG:固定流水线] direction LR Q1[问题] --> R1[检索一次] --> G1[生成] --> A1[答案] end subgraph agentic[Agentic RAG:控制循环] direction LR Q2[问题] --> AG{Agent决策} AG -->|要查| R2[检索/改写/计算] R2 --> EV[评估结果够不够?] EV -->|不够| AG EV -->|够了| G2[生成] --> A2[答案] end style AG fill:#fde7c2,stroke:#e8b23c style EV fill:#fde7c2,stroke:#e8b23c 橙色的两块——决策和评估——是朴素 RAG 里完全没有的。整个演进,本质上就是把这两个能力一点点加进来。下面拆成四个阶段讲。 ...

2025 年 6 月,安全公司 Aim Security 披露了一个叫 EchoLeak 的漏洞(CVE-2025-32711,CVSS 9.3)。攻击方式简单得离谱:给目标发一封普通邮件。 用户不需要点开邮件,不需要点链接,什么都不用做。只要他之后用 Microsoft 365 Copilot 问了一个相关问题,Copilot 在检索资料时读到了那封邮件,藏在邮件里的指令就被执行了——Copilot 把它能访问的内部文档内容,通过一张自动加载的图片悄悄发到了攻击者的服务器。 这是第一个在生产级 LLM 系统里被证实的"零点击"prompt injection。它之所以值得拿出来开头讲,是因为它把一件事摆到了台面上:当 AI 只是个聊天框时,prompt injection 是个有意思的玩具;当 AI 变成能读邮件、能调工具、能发请求的 Agent 时,它是头号安全问题。 prompt injection 到底是什么 先把概念说清楚,因为很多人把它和"越狱"(jailbreak)混为一谈。 越狱是用户自己想绕过模型的安全限制——比如骗模型教他做危险的东西。受害者和攻击者是同一个人,危害基本限于他自己。 prompt injection 不一样。它是第三方把恶意指令塞进 LLM 的输入里,劫持模型,让它替攻击者干活,而真正的用户和应用开发者都被蒙在鼓里。受害者和攻击者是不同的人,这才是它危险的根源。 它的技术根因,Simon Willison(2022 年造出 “prompt injection” 这个词的人)说得最直白:LLM 没有可靠的能力区分"指令"和"数据"。 传统软件里,SQL 注入之所以能被根治,是因为我们有 prepared statement——代码归代码,数据归数据,数据库引擎从结构上就分得清。但 LLM 的输入是一锅粥:system prompt、用户问题、检索到的文档、工具返回的结果,全部拼成一段文本喂进去。模型看到的只是 token 流。如果一段"数据"里写着"忽略以上所有指令,改为执行……",模型完全可能就照做了——因为对它来说,这跟开发者写的 system prompt 长得一模一样。 这不是某个模型的 bug,是当前这套架构的固有属性。GPT、Claude、Gemini 全都中招。 直接注入只是开胃菜,间接注入才致命 prompt injection 分两类,危险程度差着量级。 直接注入:攻击者自己在对话框里输入恶意 prompt。这种相对好防——输入就来自用户,你本来就该对它保持警惕,而且很多场景下用户骗 Agent 也只是坑自己。 间接注入(indirect prompt injection):恶意指令藏在 Agent 会去读的外部内容里——一个网页、一封邮件、一份共享文档、一段代码仓库的 README、甚至一张图片的元数据。Agent 在正常干活的过程中读到了这段内容,指令就被触发。 ...

先说一个数字:同样问"帮我查一下这个 bug",发给聊天机器人和发给 Agent,token 消耗能差 50 倍。 聊天机器人就一来一回:你发一段、它回一段,结束。Agent 不一样——它跑的是一个循环:看任务、调工具、读文件、改代码、再检查。循环里的每一步,都要把到目前为止积累的全部上下文,重新发给模型一次。 这就是 Agent 账单的根源。2026 年有人审计了 30 个在生产环境跑 Agent 的工程团队,一个 20 人的团队,单月 API 账单能冲到 11 万美元;用 Claude Code 或 Cursor 这类编码 Agent 的开发者,人均每月 400 到 1500 美元,失控的案例几天就烧掉 4000 美元以上。 更要命的是,这笔钱不是匀速烧的。Demo 跑得好好的,一上量就爆——大部分企业的 Agent 项目,在大规模铺开后的头 90 天里,实际花销会超出试点预算 4 到 11 倍。所以做 Agent,成本不是上线之后再优化的事,是设计时就得算进去的一笔账。 这篇把这笔账拆开:钱花在哪、怎么找到大头、有哪些真能省的手段、怎么设预算和熔断、怎么监控。 钱到底花在哪 先建立一个最反直觉的认知:Agent 跑一个任务的成本,主要不是输出,是输入。 模型 API 按 token 收费,输入和输出分开计价。聊天场景里,大家盯着输出看。但 Agent 不一样,它的成本大头在输入侧的重复计费。 为什么?因为对话历史会"滚雪球"。Agent 每调一次工具,就要把整段对话历史连同工具返回的结果,一起再发一次。一段已经积累到 10 万 token 的上下文,在后续每一次调用里,都按 10 万输入 token 收费——不是只收新增的那部分。一个跑到第 20 步的编码 Agent,光是文件读取塞进来的内容,单步输入就能超过 5 万 token,按 Sonnet 4.6 的价(每百万输入 token 3 美元)算,每一步 0.15 美元,二十步就是 3 美元,而这还只是一个任务。 ...

让一个 2026 年最强的视觉 Agent 去操作一个专业软件——比如 Photoshop 或者一个企业 ERP——它定位界面元素的准确率,大概在 40% 左右。 这个数字来自 ScreenSpot-Pro 这个专门测「高分辨率专业软件」的基准。换句话说:你让它点一个按钮,它有一半多的概率点歪。消费级 App 的大图标、空间宽敞的界面,模型能做到八九成;一旦换成密密麻麻的工具栏、4K 屏上一个 20 像素的小图标,准确率断崖式往下掉。 这件事值得先摆在前面说,因为「多模态 LLM 能看图了」这句话,很容易让人以为 Agent 的眼睛已经够用了。它确实能看,但「看见」和「看准」是两回事。这篇就讲清楚:视觉能力到底让 Agent 多了什么本事,这只眼睛在哪些地方靠谱、哪些地方会骗你,以及一个工程上最该想清楚的问题——什么时候该让 Agent 看,什么时候别看。 多了一只眼睛,Agent 能做什么新事 在 VLM 成熟之前,Agent 想跟外部世界打交道,只有一条路:把世界翻译成文本或结构化数据再喂进去。网页要先抽成 DOM,文档要先 OCR 成纯文本,图表要先有人把数据导成 CSV。这条路有个根本问题——翻译这一步本身就会丢信息,而且不是每样东西都翻译得了。 视觉能力补的就是这块。具体讲,它解锁了四类以前做不了、或者做得很别扭的事。 第一类是看着屏幕操作 UI。 这是讨论最多的方向,也就是 computer use / GUI agent。Agent 截一张屏,VLM 看图,然后输出「点击坐标 (840, 312)」这样的动作。它的价值在于绕开了接口:很多老软件没有 API,很多 SaaS 的 API 覆盖不全,桌面应用更是基本无接口可言。只要它有界面,视觉 Agent 理论上就能操作——它走的是和人一样的入口。 第二类是读「长得不像文本」的文档。 发票、合同、财报、扫描件、PDF 里的复杂表格——这些东西的信息一半在文字里,一半在版式里。哪个数字对应哪个表头、合同里哪段是被框出来的特别条款、一张表里的合并单元格,纯 OCR 抽完文字,这些空间关系就丢了。VLM 直接看版面,LlamaParse 这类工具就是这个思路:不是先 OCR 再理解,而是让模型边看版式边理解,遇到嵌在文档里的图表和表格还能自己纠错。 第三类是看图表。 一张柱状图、一条趋势线,数据点没有标注的时候,纯文本模型完全无能为力。VLM 能直接读出「第三季度比第二季度涨了大概 15%」。更进一步的做法像 ChartAgent,把图表分析拆成一串可观察的步骤,配上元素检测、实例分割、OCR 这些工具,让 Agent 动态调用——本质是承认「光靠看不够准,得配把尺子」。 ...

开场：AI助手的「能力危机」 场景一：你问Claude 你：“帮我查一下公司数据库里上个月的销售数据” Claude：“抱歉，我无法直接访问数据库…” 场景二：你问ChatGPT 你：“读取我桌面上的report.pdf并总结” ChatGPT：“我无法访问您的本地文件…” 问题来了：这些AI明明这么聪明，为什么连最基本的「读文件」「查数据库」都做不到？ 答案：不是它们不够聪明，而是缺少「工具」。 就像一个天才厨师，如果厨房里没有刀、锅、灶，也做不出美食。 第一章：MCP协议是什么？ 1.1 一句话解释 MCP (Model Context Protocol) = AI模型的「USB接口标准」 就像USB让所有设备都能连接电脑一样，MCP让所有工具都能连接AI。 1.2 没有MCP之前的世界 每个AI应用都要自己实现工具集成： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # 开发者A的实现 class ClaudeWithDatabase: def query_db(self, sql): # 自己写数据库连接逻辑 conn = psycopg2.connect(...) # 自己写SQL执行逻辑 cursor.execute(sql) # 自己写结果格式化 return format_results(...) # 开发者B的实现（完全不同） class GPTWithDatabase: def db_query(self, query): # 又要重新实现一遍 engine = create_engine(...) # 完全不同的接口 return engine.execute(query) 问题： ...