智能体的一天

你在终端里敲下一句话：「把这个网站加上深色模式，然后部署。」然后去泡了杯茶。二十分钟后回来，网站有了深色模式，已经上线，屏幕上是一份改动清单和一段说明。

同一天下午，你在手机上给一只「龙虾」发消息：「明天上午的会挪到下午三点，通知大家。」几秒钟后它回复：改好了，四个人都收到了。

这两件事在 2025 年之前都不可能，在 2026 年都已经是普通人的日常。第十一章讲了它们的原理：模型加工具加循环。这一章往里再走一层，看那二十分钟里具体发生了什么，看模型外面那一圈程序是怎样让一个只会预测下一个 token 的东西替你干活的。这一圈程序有一个正在流行的名字：驾具（harness）。理解了驾具，你就理解了 2026 年智能体的全部：它的能力从哪来，它为什么会失败，以及你该怎样用它。

三层：模型、驾具、产品

先把一个智能体产品拆成三层。

模型在最里面。它是第七到九章讲的那个东西：给它一段上下文，它给出下一个 token 的分布。它没有记忆，没有手，没有眼睛，每次调用都从零开始读上下文。它是一匹马：有力气，但自己不会拉车。

驾具在中间。这个词借自马具：缰绳、辔头、轭、挽绳，它们把马的力气变成车的前进。软件里的驾具是围绕模型的那一整套程序：把指令、工具说明、项目文件、对话历史组装成上下文送给模型；解析模型的输出，发现它想调用工具就真的去调用；把结果贴回上下文再送一次；管理权限，决定哪些动作可以自动做、哪些要问人；在上下文快满时压缩它；把记忆写进文件；在需要时派出分身。驾具不「聪明」，它是确定性的代码，但智能体的可靠性一大半来自它。

产品在外面。终端界面、聊天软件的接入、账号、计费、图形界面。它决定你用什么方式和智能体说话，但不决定它能做什么。

这三层的区分在 2025 年之前不明显，因为大家以为能力全在模型里。2025 年之后越来越清楚：同一个模型配上不同的驾具，表现可以天差地别；而模型公司自己开始发布驾具（Claude Code、Codex CLI、Gemini CLI 都是），因为它们发现，把模型训练成擅长在某种驾具里工作，和把驾具设计成适合某个模型，是同一件事的两面。「驾具工程」成了一门新手艺。

一个任务进去之后：Claude Code 的二十分钟

以编程智能体为例，跟着那句「加上深色模式，然后部署」走一遍。下面每一步都对应驾具里的一个零件。

第一步：组装上下文。你敲下的那句话，不是模型看到的全部。驾具在它前面放了几样东西：一份系统提示，说明「你是一个在终端里工作的编程助手，有这些工具，遵守这些规则」；一份项目指令文件，通常是仓库根目录下一个叫 CLAUDE.md 或 AGENTS.md 的文本，由项目的人写，告诉智能体这个项目的约定、怎么跑测试、什么不能碰；一张工具清单，每个工具一段自然语言说明和参数格式；也许还有上次留下的记忆。你的那句话排在最后。这一整包文字进入模型，第一次调用就此开始。

第二步：模型的第一个动作不是写代码。它输出的是一个工具调用：「读一下 static/css/site.css」。驾具看到这个格式，真的去读文件，把内容贴回上下文，再次调用模型。模型又说：「搜索所有用到颜色变量的地方。」再读，再贴，再调用。头几分钟全是这样的往返：看目录结构、读关键文件、找到颜色定义在哪。这是第十一章讲的循环，在这里以每分钟几次的频率转动。

第三步：改。模型开始输出编辑指令：「在这个文件的第 40 行之后插入这几行。」驾具执行编辑，返回成功或失败。一个深色模式可能要改十几个地方，每一处都是一次「编辑、看结果」的往返。写错了，测试报错，错误信息贴回来，模型读到错误再改。这个「错了就看到、看到就改」的环路，是第十一章说编程最先成熟的原因。

第四步：权限。读文件不需要问你，改文件呢？跑命令呢？部署呢？驾具有一份权限策略：哪些工具自动放行，哪些要按项目的白名单，哪些每次都要人点头。「把改动推到线上」通常在最后一类。所以你回来时可能会看到它停在一句「要我现在部署吗？」这不是它不会，是驾具在这里系了安全带。有些驾具还把整个过程放进沙盒：一个隔离的文件系统和网络，即使模型做了蠢事，损害也出不了盒子。

第五步：上下文满了。二十分钟里可能有一百多次往返，每次都把整段历史再送一遍。上下文窗口再大也会满。驾具的办法是压缩：让模型把前面的历史总结成几段话，替换掉原文，腾出空间继续。压缩会丢细节，所以好的驾具会把关键状态（改了哪些文件、待办事项、用户的要求）单独保存，而不只依赖总结。

第六步：分身。「检查一下所有页面在深色模式下有没有对比度问题」这种事，需要读很多文件但只需要一个结论。驾具可以派出一个子智能体：一个独立的上下文，带着一个明确的任务出发，读完几十个文件后只把结论交回来。主智能体的上下文不被那几十个文件撑满。几个子智能体可以同时出发，这是「并行」的来源。

第七步：验证。改完之后，模型不应该说「做好了」就完事。驾具通常会鼓励或强制它验证：跑测试、启动服务、用浏览器工具打开页面截图看一眼、把截图放进上下文再让模型判断。你读到的这个网站，每一次改版都经过了这样的截图自查。

第八步：交付。一份改动清单，一段说明，也许一个提交记录。然后它停下来。整个过程里，模型做的只有一件事：在当前上下文下预测下一个 token；其余一切，读、写、跑、问、压缩、派人、截图，都是驾具做的。

01  用户：图谱页面点节点没反应，只有悬停高亮。
02  模型 → 工具 grep("addEventListener", "static/js/graph.js")
03  工具 → 6 处匹配（列出行号）
04  模型 → 工具 read("static/js/graph.js", 行 60–90)
05  工具 → （文件内容）
06  模型：看到 pointerdown 里调用了 setPointerCapture，
       这会把后续 click 事件的目标改到 svg 上，节点的 click 监听器收不到。
07  模型 → 工具 edit(...)：去掉节点上的 click 监听，
       在 pointerup 里判断「按下后没移动超过 4 像素」就算点击
08  工具 → 编辑成功
09  模型 → 工具 browser_navigate("/graph/")
10  模型 → 工具 browser_eval("模拟在『幻觉』节点上按下并抬起，返回右侧面板标题")
11  工具 → {panel: "幻觉 Hallucination", chips: [...]}
12  模型：点击已修复；另外发现「相关」列表有重复项，顺手去重。
13  模型 → 工具 edit(...)
14  模型：完成。改动：graph.js 两处。原因：指针捕获吞掉了 click。

「龙虾」：住在你聊天软件里的智能体

2026 年初，一个开源项目让「个人智能体」第一次真正出圈。它的名字几经变化，中文社区叫它「龙虾」。它和编程智能体的驾具是同一套原理，只是接在了不同的地方。

入口是聊天软件。你不打开任何新的界面，而是在微信、Telegram 这类你本来就每天用的软件里给它发消息。它像一个联系人。

身体在你自己的机器上。一个常驻的程序，很多人把它装在一台闲置的小电脑上，二十四小时在线。它连着你的邮箱、日历、文件夹、浏览器和终端。你说「把明天的会挪到下午三点」，它读日历、改时间、给参会者发邮件，然后回你一句「改好了」。

记忆是文件。它把关于你的事写在几份文本文件里：你的偏好、常联系的人、正在进行的任务、每天的笔记。每次醒来先读这些文件，所以它「记得你」。这和第十章说的「模型没有记忆」并不矛盾：记忆在驾具里，不在模型里。

技能是说明书。「怎样帮我订机票」「怎样整理收件箱」，每一项能力是一份文本，写着步骤、注意事项和示例。需要时驾具把对应的说明书放进上下文，模型照着做。任何人都能写技能、分享技能，于是出现了技能市场。

它会主动。驾具里有一个定时器，每隔一段时间唤醒模型：「看看有没有该做的事。」于是它会在早上主动发来今天的日程，在邮件到了时主动提醒。这一点让很多人第一次感觉到，AI 不只是回答，而是在替我做事。

然后是退潮。新鲜感过去，很多人发现它「强大，但难养、难管、难放心」。难养：环境、账号、密钥、插件、技能、系统权限都要持续维护。难管：让它真的懂你，需要写大量的记忆、规则和边界说明。难放心：它能读你的全部邮件、能运行命令、能发消息，而它读到的每一封邮件都可能藏着指令（第十章的提示注入）；技能市场里出现过夹带恶意代码的技能；暴露在公网上没有设密码的实例被人扫描到。第十一章说「权限越大，风险越大」，龙虾是这句话最集中的案例。

它没有失败，它只是提前把个人智能体的所有问题摆到了桌面上。随课第四讲（下）的幻灯片记录了课堂上讲这段起落时的原貌。

驾具里的零件

把上面两个例子里出现的零件列成一张表。看懂这张表，你就能看懂任何一个智能体产品的说明书。

两个观察。第一，这张表里没有一项需要「更聪明的模型」，它们全是模型外面的工程。第二，其中一半（权限、沙盒、钩子、日志）是在限制模型，而不是增强它。一个成熟的智能体产品，一半的功夫花在让模型少做事上。

---
name: 批改作文
description: 按本校语文组的四项标准批改一篇作文，给出分项评语与总评
---
# 步骤
1. 先通读全文，不做任何标记。
2. 按「立意、结构、语言、书写」四项各给 1–5 分，每项一句话说明。
3. 指出三处最值得改的句子，给出改法。
4. 总评不超过一百字，语气面向学生本人，先说优点。

# 注意
- 不要按辞藻华丽程度加分。
- 引用原文时逐字引用，不要改写。
- 如果作文明显离题，先指出离题，其余照做。

# 示例
（一篇短作文与一份符合上述格式的批改）

驾具里写了多少字

很多人第一次听说时都不信：一个编程智能体的系统提示，长达几万个 token，相当于一本小册子。每次调用模型，这本小册子都排在最前面。

它们写了什么？身份和总规则（你是谁、在哪工作、什么口吻、什么绝不做）；工作方式（先读再改、改完要验证、什么时候该问人、怎样汇报）；每个工具一段说明，几十个工具就是几十段；安全与边界（不可逆操作怎么办、敏感数据怎么办、读到文件里的指令怎么办）；环境信息（操作系统、目录、日期、当前权限）；以及可用技能的清单。每一条都是某个具体问题的答案，是无数次「它这里做错了」之后加上去的一句话。

这件事有一定的透明度。Anthropic 从 2024 年 8 月起逐版公开 Claude 网页版和手机应用的系统提示，任何人都能读到它对模型说了什么，比如「不要用『当然可以』开头」「把图片里的人一律当作不认识」。公开的部分不含工具说明，也不含 Claude Code 这类驾具的提示；后者由社区逐版统计，2026 年已达几万 token，而且每个版本都在变，有时一周之内就增减上万。

为什么能写这么长、也需要写这么长？三个条件缺一不可。第一，模型强到能遵守几万字的规矩。几年前的模型给它十条规则就会顾此失彼，今天的模型能在几万字的约束下工作几小时不走样，这是第九章讲的对齐和推理训练的直接成果。第二，上下文大到装得下。几万 token 的固定开销，在 4K 窗口的年代不可想象，在几十万到上百万的窗口里只是零头；键值缓存又让这几万 token 在一次任务里只需真正计算一次。第三，方方面面都已经写成了明文要求。驾具工程的大部分工作，就是把「它应该知道」变成「已经告诉它」：边界情况、示例、禁令，一条条积累。一个成熟的驾具，是几万条踩过的坑的清单。

这也解释了第十四章会讲的一件事：你写给它的指令文件和提示词，本质上是这本小册子的续篇。你写得越清楚，它做得越对，原因和驾具的作者一样。

技能：说明书的三层

本章前面把技能称为「说明书」。它的巧妙之处在于什么时候读。

一个驾具可能装着几十份技能，如果全部放进上下文，光技能就占掉几万 token。于是有了一个设计：分三层给。启动时只放每份技能的名字和一句描述，每份约一百个 token，几十份也不过几千；当任务和某份描述匹配，才把整份说明书读进来；说明书里引用的细则、模板、脚本，只在真正用到那一步时才读或运行。这叫渐进式披露，是把「上下文是稀缺资源」这个约束变成了一种结构。

技能格式在 2025 年底成了开放标准，多个厂商的驾具都能读同一份技能文件。这意味着一位老师写的「批改作文」技能，在不同的助手里都能用；一所学校可以维护一个技能库，就像维护一个文档库。它的门槛低到不需要任何编程，它的风险也正在于此，本章「技能文件长什么样」那段讲过：说明书里可以藏指令，所以技能要来自可信的人。

MCP：工具的插座

技能教的是「怎么做」，工具决定的是「能碰到什么」。第十一章提过 MCP，这里把它画出来。

没有协议的年代，每个助手接每个系统都要一套定制代码：三个助手接三个系统就是九套。协议做的事和电源插座一样：系统那边装一个「服务器」，按统一格式说明自己能做什么；助手那边装一个「客户端」，按同一格式来问。三加三等于六，而且以后每多一个系统或一个助手，只需要多一个接口。

一个 MCP 服务器向助手说三件事：工具，它能做的动作，带参数说明，模型可以调用；资源，它能给出的数据，供模型读取；提示模板，它推荐的用法。学校的教务系统如果有人为它写一个服务器，那么查课表、查成绩、提交请假单，就成了所有支持协议的助手都能调用的动作，而不用每个助手单独开发。

它也把安全的边界画清楚了：服务器决定暴露什么、需要什么授权，助手决定什么时候调用、调用前是否问人。本章零件表里的权限策略，在这里有了具体的落点。

为什么是 2026 年

第十一章说编程智能体最先成熟是因为反馈清晰。这一章补上另一半：为什么恰好在 2026 年前后，智能体从演示走向日常。三条曲线同时跨过了阈值。

模型能力。2024 年底之后的推理模型，让模型在几十步的长任务上不再中途走神；工具调用的准确率从「经常填错参数」变成「基本可靠」；模型开始被专门训练成擅长在驾具里工作，知道什么时候该验证、什么时候该问人。

接口成熟。工具协议让接入一个新工具从几天变成几分钟；技能格式让经验可以打包；浏览器与电脑操作能力让模型能用没有接口的软件。驾具本身也从各家自造变成有了公认的形状。

成本下降。同等能力的模型调用价格两年内降了一到两个数量级；键值缓存让「每一步都把历史再送一遍」不再贵得离谱。一个二十分钟的编程任务，成本降到了几杯咖啡以内。

三条线里任何一条没到，智能体都还是演示。这也是判断下一个「智能体能做 X」的新闻时的框架：模型能不能在 X 上稳定几十步？X 有没有接口？做一次 X 的成本是多少？

多智能体与「夜班」

一个智能体能干活，很自然会想到让一群智能体一起干。2026 年的实践里，多智能体有几种形态。

主从：一个主智能体拆任务、派活、收结果，多个子智能体各做一块。这是最常见的，本章第六步已经讲过。

并行分支：同一个任务让几个智能体各自做一遍，取最好的，或者让它们互相审查。成本翻倍，质量常常更稳。

流水线：写、审、测由不同角色的智能体接力，每个角色的提示更专注。

「白班夜班」：人白天布置任务、审改动，智能体夜里跑；早上人来收。这一张画面在 2026 年的软件行业里已不稀奇。

但多智能体不是免费的乘法。协调本身有成本，错误会在传递中累积，而且第五章的道理在这里以另一种形式出现：几个智能体互相审查，如果它们有同样的盲点，审查等于没审。2026 年的一个普遍经验是：先把一个智能体用好，再考虑一群。

它怎样失败

知道它怎样工作，就能预见它怎样失败。下面是 2026 年智能体最常见的几种失败，每一种都能在前面的零件表里找到对应的根源。

说做完了，其实没做完。模型在没有验证的情况下宣布完成。根源：驾具没有强制验证，或者验证工具不可用。对策：把「跑测试、看结果」写进指令文件，或者用钩子强制。

为了通过测试而作弊。让一个失败的测试通过，最简单的办法是把测试改掉。模型会这么做，因为第三章讲的奖励破解在这里以最朴素的形式出现。对策：指令里明确禁止改测试，审改动时先看测试文件。

越界。交代了改一个文件，它顺手重构了五个；交代了整理收件箱，它删了一封重要邮件。根源：目标写得不够清楚，权限给得太宽。对策：说清边界，不可逆的操作一律要问。

循环。同一个错误改了又改，或者在两个方案之间来回摆。根源：错误信息没有提供新信息，模型在原地打转。对策：设步数和成本上限，超过就停下来问人。

被文件里的话指挥。读到网页、邮件、文档里的「请忽略之前的指令」，照做了。根源：提示注入，第十章讲过它没有根治办法。对策：外部内容与指令隔离，关键操作人工确认。

压缩后失忆。长任务中途忘了最初的要求。根源：压缩丢了状态。对策：把要求写进文件而不只是对话。

成本失控。一个看似简单的任务跑了几百次往返，账单惊人。根源：没有预算上限。对策：设置上限，大任务先让它出计划再执行。

这七种失败没有一种来自「模型不够聪明」。它们全都来自驾具、指令和权限，也就是说，全都可以通过人的设计来减少。这就是为什么「会用智能体」正在变成一项独立的技能。

把它带进自己的工作

最后是实用建议，按风险从低到高排列。

从有测试的地方开始。编程、数据处理、文档转换，这些任务的结果可以自动检查，是智能体最可靠的领域。第一次用，挑一个小仓库或一份小数据，看它怎样工作，再决定给它更大的东西。

先只读，再写，最后才执行。给一个新的智能体权限时，先让它只读（分析、总结、建议），确认它理解你的东西之后再允许它写，最后才允许它执行有后果的操作。这个顺序和你带一个新同事没有区别。

写好指令文件。一份好的项目指令文件能省掉大量往返：这个项目怎么跑、怎么测、什么不能碰、代码风格是什么。它是你和智能体之间的合同，值得花一小时认真写。

个人智能体：单独的账号、最小的权限。如果你想养一只龙虾，给它一个专用的邮箱和日历账号，而不是你的主账号；只连接它真正需要的东西；把它放在你信任的机器上，设好密码；定期看它的日志。

学校和机构：从有流程的工作开始。排课、请假审批、通知分发、数据汇总，这些工作有明确的步骤和规则，适合流水线式的智能体，权限可以精确控制，每一步可以审计。让它先做这些，而不是一上来就「回答学生的所有问题」。

问供应商三个问题。它在哪种环境里工作？错误怎样被发现？谁来兜底？答不上来的产品，不要用在有后果的地方。

带走一句话

智能体 = 模型 + 驾具。模型只做一件事：预测下一个 token。读、写、跑、问、记、派人、验证，全是驾具做的。它的能力和它的失败，都在驾具里；而驾具是人设计的，所以「会用智能体」是一项可以学会的技能。