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 集成标准。 ...

让一个 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 动态调用——本质是承认「光靠看不够准,得配把尺子」。 ...

RAG是什么 一句话：先查资料，再回答问题。 大模型直接回答问题容易编造内容。RAG让它先从你的知识库里找到相关内容，再基于这些内容回答。 1 用户问题 → 搜索知识库 → 找到相关文档 → 喂给LLM → 生成答案 最简实现 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.chat_models import ChatOpenAI # 1. 把文档切块并存入向量数据库 docs = load_and_split_documents("./docs") vectorstore = Chroma.from_documents(docs, OpenAIEmbeddings()) # 2. 检索相关内容 retriever = vectorstore.as_retriever(k=3) relevant_docs = retriever.get_relevant_documents("什么是RAG？") # 3. 生成答案 llm = ChatOpenAI() answer = llm.invoke(f""" 根据以下内容回答问题： {relevant_docs} 问题：什么是RAG？ """) 就这么简单。30行代码就能跑起来。 ...

开场：同样的问题，天差地别的回答 先看一个真实场景： ❌ 普通人的提问： “帮我写一篇文章” AI回答：好的，请问您想写什么主题的文章？（然后开始无尽的追问…） ✅ 高手的提问： “你是一位资深科技博主。请用轻松幽默的语气，写一篇800字左右的文章，介绍AI编程助手（如Cursor、Copilot）如何改变程序员的工作方式。文章需要包含：1个生动的开场故事、3个具体的使用场景、1个数据对比、结尾的行动号召。” AI回答：直接输出一篇结构完整、语气生动、可直接发布的高质量文章。 这就是提示词工程的魔力。 第一章：CRISP框架 —— 黄金提示词公式 我总结了一个简单易记的框架：CRISP 字母 含义 说明 C Context（背景） 告诉AI"你是谁"和"场景是什么" R Role（角色） 让AI扮演专家身份 I Instructions（指令） 清晰的任务描述 S Specification（规格） 输出的格式、长度、风格 P Proof（示例） 给出1-2个例子（Few-Shot） 实战模板 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # 背景 (Context) 我正在为技术博客写一篇关于[主题]的文章，读者是有一定编程基础的开发者。 # 角色 (Role) 你是一位拥有10年经验的资深技术作家，擅长用通俗易懂的语言解释复杂概念。 # 指令 (Instructions) 请帮我撰写这篇文章，要求： 1. 开头用一个真实案例或故事引入 2. 核心内容分为3-4个要点 3. 每个要点配有代码示例 4. 结尾总结并给出行动建议 # 规格 (Specification) - 字数：1500-2000字 - 语气：专业但不枯燥，适当加入幽默 - 格式：Markdown，使用代码块、列表、表格 # 示例 (Proof) 类似风格的文章参考：[给出一段示例文字] 第二章：Chain of Thought —— 让AI学会思考 核心原理：不要让AI直接给答案，让它先"想一想"。 ...

开场：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) 问题： ...

早上8:00 - 开工！今天又是「搬砖」的一天 当你还在挣扎要不要再赖床5分钟时，你的AI Agent已经开始工作了。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 # Agent的早晨例行任务 class MorningRoutine: def __init__(self): self.tasks = [] self.priority_queue = PriorityQueue() async def start_day(self): """开始新的一天""" # 1. 检查邮件，筛选重要信息 urgent_emails = await self.check_emails() # 2. 查看日历，准备今天的会议 meetings = await self.prepare_meetings() # 3. 扫描Slack/钉钉，看看有啥新消息 notifications = await self.scan_channels() # 4. 生成今日工作清单 return self.create_daily_plan( urgent_emails, meetings, notifications ) 真实场景： 某科技公司的产品经理小王，每天早上收到的邮件平均80封。自从用了AI Agent后，Agent会自动： ...