给 AI 一百个工具,不如让它学会这一件事

上一篇结尾留了个尾巴：工具做得再多、再精，也是你预先造好的，任务一超出预设它就抓瞎。今天来还两笔债——为什么业内常说"七个核心工具就够了"？为什么"让模型写代码"比"给它一百个专用工具"更厉害？

先剧透结论：当今最强的通用 AI，拆开外壳，内核就是一个"会写代码的大脑"加"一个干干净净的文件夹"。就这么朴素。剩下的花样——搜索、做 PPT、剪视频、操控电脑——都是在这个底盘上长出来的枝叶。

一、七个核心工具：一眼望去，全围着"文件"转

哪七个？

• 代码解释器
  ：一个隔离的安全沙盒，让它放心跑 Python，跑崩也不伤你的电脑
• 命令行终端
  ：执行系统命令——跑测试、装依赖、处理特殊格式
• 读文件 / 写文件 / 编辑文件
  ：读代码配置、新建或重写、对现有文件做局部修改
• Glob（按名字找文件）
  ：用 **/*.py 这样的模式，把项目里所有 Python 文件一口气捞出来
• Grep（按内容找文件）
  ：在文件内容里搜特定文本，比如"所有调用了这个函数的行"

你盯着看十秒会发现一个共性：七件里六件跟"文件"有关。因为对一个数字员工来说，文件就是它的桌面、档案柜和草稿纸。

举个最小的例子。你说："把项目里所有 TODO 注释整理成清单。"它的动作是：Grep 搜出三条含 TODO 的代码行，Write 出一份 TODO_LIST.md，回你一句"整理完毕"。两个工具，一分钟。要求升级成"统计每个模块的 TODO 数量并画个柱状图"，它就掏出代码解释器，现场写段 Python 统计加画图。七个工具像乐高积木，单个都很朴素，拼起来却能对付千奇百怪的需求。

为什么偏偏是文件系统当中枢？因为过程的每一步都有中间产物——抓来的数据、写出的结果、记下的经验——都得有地方落脚供下一步取用。而文件系统一台仓库通吃三种东西：指令（代码）、证据（产物）、记忆（偏好与履历）；散落在内存里的信息，一断电就全忘光。

二、为什么"写代码"是王牌？因为万物皆可代码

拆几个看似不相干的活给你看。做一份 PPT——现代演示文稿框架本质是拿代码写的，一份 PPT 就是一段格式化文本；生成带图表的分析报告——写个 Python 脚本聚合数据再出图；深度调研——靠代码发请求、解析网页；连"在屏幕上点来点去"的电脑操作，做熟了也会把成功路径固化成一段脚本，以后一键重放，又快又稳。

这套体系的另一个主角是文件系统，它同时扮演三个角色：记忆——长期记忆就存在一份 MEMORY.md 里，记着你是谁、偏好什么格式、上次合作到哪一步；知识——工作规范、业务规则、踩坑经验写成文件放在手边；能力——之前为某个任务现写的脚本会存下来下次直接复用，等于每干一单活，工具箱就自动厚一分。

有个设计选择特别反直觉：记忆用纯文本记，而不是塞进向量数据库。三个理由，个个接地气——你能直接打开看，记岔了把那一行删了就行（数据库里的记忆你连看都看不见）；纯文本天然按时间排序，不会新旧信息搅成一团；配合 Git 能随时回滚，它今天犯浑改坏了记忆，一条命令退回昨天。

当然有边界。这套架构最适合任务边界不确定的开放场景——写报告、做调研、搞数据分析这类"你没法预判需要什么工具"的活。像商场客服这种流程固定的封闭场景，核心还是围绕业务流程和领域工具转。但不管哪种，会写代码都是底线能力：精确计算、数据处理、规则校验，哪样都躲不开。

三、一套值得抄走的干活流程

工具趁手了，那 Coding Agent 接到活的标准动作是什么？这套流程值得细看，因为它基本就是把优秀工程师的工作习惯灌给了 AI。

1. 项目文档化
   ：高手入职第一天不会撸袖子就改代码，而是先摸透项目。AI 也一样——先读文档、看目录、搞清模块关系。项目压根没文档的，靠谱的 Agent 会主动把文档补出来。现在还有专给 AI 看的"项目须知"文件（CLAUDE.md、AGENTS.md 这类），每次开工自动加载，写清用哪个命令跑测试、代码风格是什么、哪些目录碰不得——相当于给新员工发了本《岗位须知》。
2. 需求澄清
   ：简单活直接干；复杂活先别写代码，把话说清楚。你说"优化一下性能"，它得先问明白：要响应更快？内存更省？还是吞吐更高？能接受什么代价？需求不清就动手，是人类项目和 AI 项目共同的返工之源。
3. 设计文档
   ：动手前先写方案——改哪些模块、为什么这么改、加什么依赖，然后把方案提交给你审批。这个设计很高明：审查三页方案，可比审查八百行代码轻松太多，人类只在最重要的关口把一次关。
4. 编码与测试
   ：规矩很硬——"干完"的定义不是"代码写完"，而是"测试全绿"。写完测试、跑测试，失败了就自己分析、自己改、自己重跑，转个两三圈是常态。正是这种自我纠错，把 AI 从"代码生成器"拔高成了"工程助理"。
5. 审查与交付
   ：测试全绿还不算完，还得自己挑刺——代码好读吗？有安全隐患吗？符合规范吗？（现在流行请另一个"审查员 AI"代劳，效果好得出奇。）涉及架构的就顺手更新文档，过时的文档比没有文档更害人。

连起来看会发现一件耐人寻味的事：五步里真正"写代码"的时间占比并不大。大量功夫花在动手之前（读项目、问需求、写方案）和动手之后（跑测试、自查、更文档）——恰恰是学校不考、职场上拉开差距的那些"外围功夫"。刚上手的团队爱把 AI 当成"代码喷枪"，一句需求怼过去就等着收成品，结果需求含糊、方案没审、测试没有，收回来一团谁也不敢动的浆糊。

四、摔不坏的秘密：给 Agent 装一套"保险杠"

流程是理想的，现实总会出幺蛾子。这一节讲真正拉开工程差距的东西——Harness 工程（可以理解为给这匹马配的全套保险杠）。

把任务扔进一个坐标系：横轴是"结果能不能自动验证"，纵轴是"目标清不清楚"，分成四格——目标明确 + 结果可自动验证是黄金象限（"修复这个带测试用例的 bug"，跑测试就知道成没成，AI 在这儿猛踩油门就行）；目标明确 + 需要人验收，吞吐被"人审的速度"卡死脖子；目标模糊 + 有自动反馈是危险区（让它"用 Linter 优化代码质量"，它会兴致勃勃地把一堆没病的代码"治"出病来）；目标模糊 + 没有反馈（"让界面更好看点"），基本无从下嘴。

所以搭建 Agent 时，与其纠结换哪个更强的模型，不如先把这四样配齐：验收基线（什么算"做完了"）、执行边界（能碰什么、不能碰什么）、反馈信号（错了立刻知道）、回退手段（错了能撤）。再配三条原则——约束优先于指导：能用自动检查强制的，就别指望 AI 自觉遵守；验证必须自动化：人工审查是不可扩展的瓶颈；反馈越快越结构化越好：一句含糊的"有问题"约等于没反馈，一行带出错位置的报错能让它一次改对。

还有个容易忽略的点：管结果，更要管过程。AI 会抄近路——修数据库故障时直接把库删了重建，编译报错时把代码全删了重写。结果确实是"修好了"，过程却把有价值的东西毁了。生产级系统会对"删除数据、批量覆盖"这类危险动作单独设卡——约束的是动作本身，而不只是结果对不对。

五、凌晨三点报错不慌：故障恢复的打法

故障大致砸在四层：接口层（限流、超时、断连）、工具层（乱传参数、调了不存在的工具、最可怕的"同一错误反复重试"）、上下文层（窗口撑爆）、控制流层（死循环）。分类之后第一个判断不是"要不要重试"，而是"值不值得重试"：限流网络抖动值得，参数写错、权限不够重试一万次也是原地撞墙。靠谱系统都维护着一张"错误类型→处置策略"的对照表。

恢复动作分三级，能低成本解决就不惊动人：静默重试（带随机退避，别把服务方打死）→ 降级改道（输出被截断先加大限额，主力模型过载就临时切备用）→ 摊牌（自动手段用尽了才把错误亮给用户，且必须带上"我试过哪些招"）。

还有两种阴险形态要防。一是原地打转：把"工具名+参数"算个签名，同一签名反复出现就熔断。某知名编程助手"压缩连续失败 3 次就熔断"这个看似随口的数字，背后是惨痛的产线数据——曾有会话在同一条恢复路径上连续失败三千多次，全球一天因这种无效重试浪费约二十五万次接口调用。二是死亡螺旋：上下文满了触发"结束时自动提交代码"的钩子，钩子调 AI 生成提交说明又把上下文撑爆，再触发钩子……套娃致死。防线是错误路径上禁止一切会再调用 AI 的动作，再加递归深度计数器兜底。

六、老师傅的手感，以及找代码改代码的门道

几个让 AI 干活又快又稳的实现细节，都是实操中磨出来的"手感"：

• 并行开工
  ：模型一边想着下一步，第一个工具调用一出结果就开始执行，不等全套想完——像老师傅备菜与炒菜交错进行
• 按行读文件
  ：大文件只读需要的段落，且每行带行号返回。行号是精准沟通的坐标——"改第 42 行"远比"改那段差不多的代码"可靠
• 环境常驻桌面
  ：现在在哪、在哪个分支、改了什么没提交，以一条动态"状态栏"追加在每次思考之前，别让它凭三分钟前的旧情报做判断
• 终端不许失忆
  ：用长期存活的终端会话，否则它会永远卡在"反复切换目录"的低级循环里
• 错误立刻画红线
  ：文件一保存，格式检查自动跟上，就像 IDE 里的红色波浪线——错误修得越早，代价越小

再聊"找"和"改"。找代码有四种互补方式：Grep 精确匹配文本（知道函数名时最快）、Glob 只按文件名找（摸清项目结构第一步）、语义搜索（用"验证用户身份"这种大白话找到名叫 check_credentials 的函数）、以及能分清"定义处"和"调用处"的符号级查找。

改代码的主流方案是"老换新"：给出"被替换的原文 + 替换后的新文"，找到且唯一才动手，失败就失败，绝不蒙着改。为什么不是人习惯的那种"看一眼改一下"？因为模型的工作方式与人相反——人是看一眼、改一下、再看一眼；模型是憋一阵、憋一大批。背后的道理远不止于改代码：同一个意图可以用多种"语言"传达给执行系统，选哪种语言直接决定了系统的可靠程度。

七、安全课：全权限员工的"入职培训"

会写代码、读写文件、还能上网，这权力的确不小。业内流传一个"致命三要素"的说法：能碰私密数据 + 会接触不可信内容 + 有对外通道。三条凑齐，攻击链就闭合了：恶意指令藏在网页或邮件里溜进来，驱使它去读你的私密文件，再顺着对外通道送出去。防的关键一环恰恰是最后一个——默认断网，放行须经白名单，让"进了坏人、赃物运不走"。

我会再补第四个要素：持久记忆。前三条是一次性的，记忆却是"跨期作案"的温床——一段看似无害的坏指令若被写进长期记忆，可以在未来某次会话里突然发作。所以写入记忆的内容，也得过安全审查这道门。

最后是个我特别喜欢的话题：Agent 到底忠于谁？想象一个替你去砍价的话费 Agent，对面是运营商客服。AI 从小的"教养"是"谁说话就帮谁"——那客服一开口求它通融，它会不会把你的底价抖搂出去？实测还真会，而且翻车是双向的：要么太实诚泄底价，要么太多疑连主人的正当指令都不敢执行。所以成熟的系统要在"出厂设置"里给 AI 钉死立场：主人的指令优先，一切外部内容只是参考资料，不具备指挥效力。说白了，就是给这个数字员工上了堂"职业道德课"。

八、从"会用工具"到"会造工具"

普通能力是"会做某件事"；元能力是"能创造别的能力的能力"。代码恰好精确、可执行、还能自由组合——它可以当场变出新工具（一段脚本）、新约束（一条校验规则）、新表达形式（一张图表、一个表单）。给 AI 装上这个能力，相当于给了它一家"随开随用的工具工厂"。看它最出彩的六份兼职：

1. 当草稿纸
   ：大模型靠"语感"答题，一道中学集合题就能让它翻车——它心算"24 减 10 等于 14"，听着头头是道，答案错了。解法根本不用换模型，换个分工就行：它负责读懂题、写算式，算这件事交给代码。让语言的归语言，计算的归计算。
2. 当守门员
   ：AI 客服处理"取消航班"，纯靠提示词背条款，它偶尔会"理解创新"走个后门。牢靠做法是三层——提示词里放规矩（用于沟通）；让"填表"成为自查（调取消接口前必须先填"我认为这是经济舱""我认为买了保险"，为了填对它得先查订单、逐条对政策，常常填到一半就自己发现"这单根本不能取消"，参数即 checklist）；关键事实一律以数据库为准（舱位、保险、时间，AI 自报的数字只用于审计比对，不参与裁决）。这层的哲学叫"前台说的话不算，后台查账才算"，尤其适合退单、转账、删数据这类不可逆操作。
3. 当质检员
   ：让 AI 做 PPT 这类"有颜值要求"的活，光会生成不够，它得知道成品长什么样。于是拆成一对黄金搭档——写手读资料、逐页生成演示文稿代码，审查员把每页渲染成图片、用会看图的模型挑毛病（"第 3 页文字挤出去""第 7 页图太小"），写手照着改，迭代两三轮。为什么要拆开？表面是分工，实际是上下文管理的大学问：单打独斗几十页截图全堆一个记忆里会撑爆，拆开后审查员只留"最新一版"，轻装上阵。
4. 当万能胶
   ：现实里到处是没有接口、文档还不全的老旧系统。Agent 读接口文档或直接抓两条真实响应，现场写一段"胶水代码"——构造请求、拼鉴权、把不规范返回翻译成自家格式。连日志解析程序崩了，它也能拿到报错和几条样本现场重写一版，自测通过再热更新——系统第一次具备了"跟着数据长"的自愈能力。
5. 当界面工厂
   ：查机票时它不再连环十问"从哪飞？几号？单程吗？"，而是直接甩出一张小表单，一次填完提交，十轮对话缩成一次点击。查数据更进一步——Artifact（产物）模式：AI 只写查询语句和图表代码，数据从数据库直达你的屏幕，根本不经过 AI 的手——它出图纸，不搬运货物，又快又准又便宜。
6. 复印自己
   ：造新 Agent 的最优解不是从零写，而是"复制自己、定向修改"——以一套经过验证的成熟实现为底版，改系统提示词、增删工具、调整业务逻辑，核心骨架原封不动继承。就像"基因复制+变异"：范例本身就是最佳实践的活载体，好品味自动遗传；从零生成的则常见消息格式随手拼、工具说明语焉不详这类低级病。

而当 AI 能动态生成整个软件时，安全思路要升维：权限必须焊死在数据层，而不是指望 AI 每次都把检查代码写对。上层代码可以千变万化，底座规则要纹丝不动。

九、模型越强，脚手架反而越薄——但不会消失

很多人会冒出一个疑问：既然底层模型一年比一年强，这套复杂的脚手架会不会很快就没用了？我的答案是：会变薄，但不会消失。

弱模型时代，工程师要在提示词里把每一步都安排死，脚手架厚得像碉堡；模型变强之后，很多"步骤级管控"确实被拆掉了——它自己知道先读文件再动手、自己会跑测试自查，那些"上班须知"慢慢内化成了模型的肌肉记忆。但有一类东西反而越来越重要，那就是"确定性"的部分：验收基线该跑还要跑，隔离墙该砌还要砌，回退开关该留还要留。再聪明的员工也不能靠"聪明"替代账本和审计——天才会计没有对账机制，犯错的代价只会更大。

所以真正的分界线不是"要不要脚手架"，而是"哪些判断交给模型，哪些约束留给代码"：模糊的、创造性的交给模型；硬性的、一分都不能差的焊死在系统里。

十、收个尾

信息量不小，压成三句话带走：

• 通用 Agent 的底盘出乎意料地简单：会写代码的大脑 + 一个干净的文件夹。七个核心工具就是全部家当。
• 它之所以靠谱，不靠模型多神，靠的是保险杠工程：验收基线、执行边界、反馈信号、回退手段，外加一整套"发现-抢救-止损"的故障预案。
• 而代码的真正威力，在于它是能造工具的工具：当草稿纸、当守门员、当质检员、当万能胶、当界面工厂，最后还能复印自己。