25.2 最小可行智能体
模型: gpt-5.4 (openai/gpt-5.4) 生成日期: 2026-04-01 书名: AI编码智能体 章节: 第25章 — 构建你自己的智能体 Token 消耗: ~4,500 输入 + ~1,450 输出
如果第25章只有一条建议,那就是:先做一个最小可行智能体,而不是一上来就追求“最大想象架构”。早期目标不是复制 OpenCode、Oh-My-OpenCode、Claude Code 的全部能力,而是先造出一个能做真实工作、会以可观察方式失败、并且能教你下一步该加什么的小系统。
最稳妥的起点,就是 ReAct loop 加五个核心工具:read、write、bash、grep、glob。
25.2.1 为什么 ReAct 仍然是最好的起点
ReAct 可以理解为一种“推理—行动—观察—更新—重复”的循环结构。它的价值不在于概念新,而在于它能抑制幻觉。只让模型想,模型很容易脑补仓库细节;强迫它去读文件、搜代码、跑命令、再回头修正判断,它才会被现实锚定。
一个最基础的循环可以写成:
- 理解用户目标;
- 判断缺什么信息;
- 用工具去环境里找信息;
- 形成或更新计划;
- 做一次边界清晰的修改;
- 验证结果;
- 继续或停止。
就这么简单,但已经足够构成一个可用的工程助手。
25.2.2 为什么是这五个工具
推荐的起步工具集故意很朴素。
Read 用来读取源码、配置、测试、日志、文档。没有可靠读取,后面几乎全是猜。
Write 用来创建或覆盖内容。无论底层实现是整文件写入、结构化编辑,还是补丁应用,本质都是让智能体能把修改真正落盘。
Bash 对应真实执行面:构建、测试、包管理、格式化、脚本、容器、运行时检查,都要通过它进入系统环境。
Grep 对应内容搜索。当智能体知道自己在找什么概念,但不知道它在哪个文件里时,grep 通常是最快路线。
Glob 对应文件发现。它帮助智能体在还不理解仓库时,先建立一个粗略地图。
这五个工具合起来,刚好覆盖人类工程师面对陌生代码库时的基本动作:发现、查看、搜索、修改、验证。
25.2.3 这个 MVP 已经能做什么
不要小看这样一个最小系统。
仅靠这套循环和这五个工具,智能体已经能修小 bug、加窄功能、更新测试、改配置、修文档、做不少维护类工作。它可以先定位问题,再找到相关文件,修改后跑测试,最后说明改了什么。
更重要的是,它能暴露你系统真正的薄弱处。你会很快看见:模型在哪里喜欢猜、哪些工具输出噪声太大、计划在哪里漂移、编辑何时不安全、验证为什么太浅。这些经验,比你过早实现复杂编排更值钱。
25.2.4 真正重要的不是“功能少”,而是“行为稳”
很多人把 MVP 误解成“功能越少越好”。在智能体设计里,MVP 更准确的意思是:用最小复杂度换取足够可靠的行为。
因此,早期应该把精力花在这些地方:工具描述是否清楚、输入输出 schema(结构约定)是否稳定、工具行为是否有边界、停止条件是否明确、计划是否能轻量保存、完成前是否强制验证。
一个只有五个好工具、但验证纪律很强的智能体,通常比一个二十个工具、行为却模糊的系统更有用。
25.2.5 按真实痛点扩展,而不是按想象中的完整版扩展
当这个 MVP 已经可用时,你应该根据反复出现的失败去扩展,而不是根据架构野心去扩展。比较合理的顺序是:
- 更安全的编辑能力,例如 patch 或 diff;
- 更聪明的导航能力,例如 LSP(Language Server Protocol,语言服务协议,用于符号级导航与诊断)或 AST(Abstract Syntax Tree,抽象语法树,用于按代码结构而非纯文本理解程序)搜索;
- 会话连续性,支持中断恢复;
- 权限控制,尤其是命令执行与写文件;
- 外部集成,例如 MCP;
- 委派,只有当单智能体已经稳定时,再考虑子智能体。
这个顺序并不随意,它符合早期智能体最常见的痛点曲线。大多数第一代系统不是输在“没有多智能体”,而是输在读不准、改不稳、记不住、验不全。
25.2.6 必须克制工具膨胀
Tool bloat(工具膨胀)是让智能体快速变差的常见路径。
每次失败都很容易诱发“再加一个工具”的冲动。找不到代码,就加代码地图;忘了计划,就加 planning tool;改坏文件,就加 refactor tool;看不懂搜索输出,就加 summarizer。
有时这确实必要,但很多时候问题不在工具缺失,而在工具说明含糊、输出格式混乱、提示词约束不足,或者压根没有验证步骤。加工具可能只是把真正的问题遮住,同时还提高了模型的选择负担和维护成本。
因此,一个默认问题应该是:现有工具集真的不够,还是我们还没把它们用清楚、用稳定?
25.2.7 一个紧凑但重要的心智模型
最小可行智能体,其实只要承担三类职责:感知现实、改变现实、检查现实。
如果你的系统能把这三件事做好,它就已经具备一个真正 coding agent 的基础。
25.2.8 从这里开始
所以,构建者到底应该从哪里开始?从 ReAct 循环开始。给它 read、write、bash、grep、glob。把工具描述写清楚。把验证变成强制环节。然后把系统投入真实任务。
不要按野心扩张,要按证据扩张。观察它如何失败,给失败分类,再一层层增加能力。小系统之所以能长成严肃系统,不是因为它一开始就很大,而是因为它每一步扩张都建立在真实需要上。