1. 从"能问答"到"能干活"：智能体到底多出了什么

聊天机器人聊得风生水起，但真让它把手头的事办了，十有八九会卡壳。这是我在写这个系列时最常被问到的问题：既然大模型已经能写代码、能总结文档、能调用工具了，为什么还要单独造一个"智能体"的概念？直接用模型不就行了吗？

先说结论：智能体不是一种新的模型，也不是某个特定框架，而是一种以"循环"为核心的使用模式。普通问答是"你说一句，我答一段"，而智能体面对的则是"你给一个目标，我自己负责观察环境、拆任务、执行操作、看结果、再调整下一步"。这个"观察—决策—行动—反馈"的闭环，才是智能体区别于普通模型应用的分水岭。

拿编程场景举例子。你让一个普通对话模型"帮我看看这个项目为什么编译不过"，它能基于上下文窗口里的内容给出猜测，但真要让它在你的仓库里翻日志、改配置、跑测试、看报错，再决定是回滚还是继续改——单靠一次生成是不够的，它需要站在"真实环境"里持续获取反馈，把原本一次性的推理变成一串有目的、有检查点的动作。

这个系列走到第 04 篇，我想把这层窗户纸彻底捅破：智能体的核心能力到底有哪些？这些能力是怎么分工协作的？以及大家天天挂在嘴边的"工作流""RAG""多智能体""平台搭建 vs Python 自建"这些概念，相互之间究竟是什么关系。读完以后你至少能达成一件事：再看到任何号称"智能体"的产品或开源项目，能第一时间判断它到底是真智能体，还是只是披了层智能体外壳的固定流程。

2. 拆开智能体的核心能力：感知、规划、行动、反馈

在没有标准教科书的前提下，我习惯把智能体拆成四个能力层来理解。这四层不是严格的代码模块，而是一种描述框架——任何自称智能体的系统，最后都跑不出这四个动作。理解它们，比你背十个框架 API 有用得多。

2.1 感知层：上下文从哪里来，记忆怎么管理

智能体要"干活"，首先得有"眼睛"和"耳朵"。感知层解决的是这样两件事：一是把外部环境里跟当前任务相关的信息收集进来，二是把历史信息组织成长短期记忆。

短期记忆通常就是模型上下文窗口里放的内容。比如让智能体改代码，最常见的做法是先把目录结构、关键文件片段、当前报错信息塞进上下文。长期记忆则复杂得多，可能是向量数据库里的历史项目经验，也可能是总结出来的用户偏好备忘录。很多初级实现只在短期记忆里反复塞东西，结果 token 越用越多、模型越答越糊涂，这就是没把感知层的"记忆管理"当回事。

另一个常常被忽略的感知能力是工具发现。智能体面对一个任务时，得知道现在手上有什么工具可以用，每个工具是干什么的，参数长什么样。现在社区里常用的 MCP（Model Context Protocol）就是给感知层建"统一接口"：把文件系统、数据库、浏览器、代码执行器都封装成标准化工具描述，让模型能"看见"可用的操作面。感知层越清晰，规划层才不至于瞎指挥。

2.2 规划层：把一个目标变成一串可执行的步骤

规划层的任务，是把"修复登录接口 500 错误"这种模糊目标，拆解成有序动作：先复现请求、查看应用日志、定位到的异常栈、检查相关代码段、修改代码、跑测试验证。

大模型的规划能力来自它自身的推理能力，但工程上不能让模型自由放飞。业界普遍的做法是"框架约束+模型发挥"结合：要么让模型输出结构化的计划 JSON，要么由代码逻辑指定思考模板。以编程智能体为例，很多系统会要求模型先输出一个next_action字段，里面写明调用哪个工具、传什么参数、为什么这么做。这样既保留了模型的灵活性，又能让外层代码稳定地驱动循环。

这里要泼一盆冷水：规划层最容易被过度吹捧。实际项目里，智能体规划得漂不漂亮，远不如"规划能不能落地"重要。一个三步计划，如果第二步依赖的错误信息根本没感知到，那整个计划就是空中楼阁。这也是为什么我在后面的实操章节里会反复强调：先保证感知闭环，再谈高级规划。

2.3 行动层：工具调用和真实环境执行

规划说得再天花乱坠，最终都要落到行动层。智能体行动的手段通常有三类：直接调用工具（比如调一个天气 API）、写代码或者执行命令（比如在沙箱里跑一段 shell）、操作界面（比如浏览器点击、桌面自动化）。

在编程场景里，行动层最核心的是"代码执行器"和"终端模拟器"。智能体生成一段 Python 脚本或者 shell 命令，然后在隔离环境里执行、拿输出，再继续下一步。这里有一个工程细节特别值得注意：行动结果必须结构化地返回给模型，不能只是一段生文本。我建议至少包一层{action_id, status, stdout, stderr, duration}的结构，让反馈层能精确判断某次行动到底成没成。

行动层的边界也必须在代码里写死。什么命令允许跑、哪些目录可读写、是否能访问公网，都需要白名单约束。让智能体在一个无限权限的环境里自由执行命令，等于是把系统的后门交给了概率。这在我的实操习惯里属于"优先级最高"的安全红线。

2.4 反馈与自主容错：让系统在错乱中活下来

反馈层是整个智能体工程里最体现功力的部分。模型不是每次决定都正确，工具执行也可能报错，网络还可能超时——一个没有容错机制的智能体，跑不了几步就会死循环或者提前放弃。

我在实战中总结了一套基本的容错链条：超时控制 → 重试策略 → 状态回退 → 人工介入。

先说超时控制：每一轮模型的调用、每一次工具执行都要设置明确的超时时间，这是最容易被新手忽略的。没有超时，一个卡死的工具执行能把整个智能体的进程拖死。其次是重试策略，但要讲究"有限重试"，比如最多重试两次，第二次必须换一种方案，否则就在原地打转。然后是状态回退：如果某一步执行失败，系统要能放弃当前计划、回到上一个已知稳定状态，而不是带着脏数据继续跑。

链路末尾是人工介入。我的原则是：智能体的自主性体现在它能把绝大多数常规问题自己消化掉，但仍要保留一个"不确定就停下请示"的通道。把"不知道什么时候该停"的问题，留给一个永远保持警觉的看门狗进程，这才是可靠的工程实现，而不是指望模型自己在 prompt 里记住"要小心"。

3. 概念辨析：哪些东西经常被当成智能体，实际上却不是

"智能体"这个词被用到发麻，工具链和平台也都想蹭这个热度。我这几年搭过不少系统，也踩过不少因为概念混用而选错架构的坑，这里挑几组最容易混淆的对比，讲清楚边界。

3.1 智能体 vs 工作流（Workflow）

很多人以为用了 LangChain 或者 Coze 拖几个节点就是智能体了，其实那多半只是工作流。两者的核心差异在控制流上：工作流是固定的有向无环图，A 执行完走 B，B 出什么结果走 C，每一条路都是预先定义好的；智能体的控制流是模型根据当前结果动态决定下一步。

举一个很具体的例子。一个客服工作流可能长这样：用户输入 → 判断意图 → 转人工或者返回知识库答案。这条链路是写死的。但真正的客服智能体，会在回答一个问题后自己决定："这个用户还在追问，我需要再查一下订单系统；如果订单接口报错，我就先解释再换个查询方式"。它的下一步不是预先画好的，而是每个回合实时生成的。

该选哪个？如果你的业务路径非常稳定、变化极少，工作流比智能体更稳、更便宜、更好调试。如果任务变化多端、需要灵活试探，再考虑上智能体。为了"显得智能"而无脑上智能体，是我见过最常见的资源浪费。

3.2 智能体 vs RAG（检索增强生成）

RAG 经常被当成智能体的同义词，这也是一大误解。RAG 的完整链路是"检索知识库 → 拼进上下文 → 生成回答"，它解决的是让模型"知道更多私域知识"的问题，本质上仍然是一个单轮或简单的多轮生成系统。RAG 不会主动决定"我要检索两次"或者"这次检索没结果，我应该换个关键词再查一次"。

而智能体可以把 RAG 当成一个普通工具来调用。比如编程智能体在排查问题时，先判断"这个报错可能跟某个内部库有关"，然后调用一个"内部文档检索工具"去查资料，查完了再决定下一步。这里的 RAG 只是智能体的抓手之一，不能反客为主。顺带提醒一点：如果只是做"文档问答"这种固定需求，老老实实做 RAG 比硬套智能体成熟得多。

3.3 Function Calling（函数调用）等于智能体吗

这是另一处高频误区。Function calling 只是一种模型输出结构化调用指令的能力，它让模型"能调用函数"，但调完函数之后呢？模型不会主动分析执行结果、不会再做决策。这套循环还得由外部代码来驱动。

把两者分开想就清楚了：函数调用是智能体的行动层必备技能，但智能体还包含规划、感知、反馈这另外三件套。一个只有 function calling、没有任何循环机制的演示项目，最多算"支持工具调用的聊天机器人"，还远够不上智能体。

下面这个表格给几个高频概念做个快速对焦：

3.4 单智能体 vs 多智能体协作

多智能体是这两年特别火的方向，但火不代表着就该用。单智能体模式下，一个大脑干所有事：感知、规划、行动、反馈都集中在同一个模型循环里。它的优势是上下文相对统一、调试成本低；劣势是上下文一长就乱，任务太复杂时工具切换频繁、效率低。

多智能体则把职责拆给多个"角色"，比如一个 Planner 负责拆任务，一个 Coder 负责写代码，一个 Reviewer 负责审查。常见的架构是一个中央协调者（Orchestrator）统一调度，也有人做更对等的协商模式。多智能体的核心挑战不是"怎么让模型当多个角色"，而是通信协议与状态共享：两个子智能体之间怎么传递中间结果，某个子智能体卡住了谁来接管，子智能体之间产生冲突听谁的。

我的实际建议是：起步阶段先做单智能体，把单一循环调稳了，再根据瓶颈决定要不要拆多智能体。一上来就上多智能体的项目，十有八九会泯灭在调试地狱和 token 费用里。同时，"角色分工"带来的收益，必须能覆盖多出的通信开销和状态同步复杂度，否则就是亏本买卖。

3.5 平台搭建的智能体 vs Python 自建的智能体

这是最近被问得特别多的问题，我用一张对照表把它说清楚：

我的判断很简单：如果你要的是快速试错，平台搭建足够；如果智能体要接入你们的业务系统、处理敏感数据、或者需要高度定制策略，那 Python 自建几乎是必由之路。这两种方式不是对错关系，而是边界关系——把平台当 Prototype，把自建当交付，是我最推荐的组合拳。

4. 光有"能力"不够，还得可测、可控、可协作

把智能体的能力拆完，很多人就急着冲去写代码了。但让我用这几年的沉痛教训告诉你：智能体能不能真正上生产，拼的不是它有多聪明，而是你有多了解它在各种边角情况下的表现。这一章的内容在一般的功能拆解文章里很少被讲透，但恰恰是工程实践里最有价值的部分。

4.1 怎么"面试"一个智能体：测评设计与回归

智能体的输出有概率性，所以它不能像普通函数一样只写两三个单测就收工。我推荐的做法是建立一套"智能体面试题"：拿出一批有标准答案或至少有人类共识答案的典型任务，统一跑一遍，看完成率和完成质量。每改一次 prompt、换一次模型、调一次工具参数，都要把这套题重新跑一遍，这就是智能体的回归测试。

比如做编程智能体，我会准备三组用例：一组是明确 bug 修复题，一组是需求模糊、需要追问澄清的任务，一组是注定失败的"环境有陷阱"场景——看它能不能识别出不可行、及时停下而不是硬编一个结果。面试题不在于多，而在于区分度：要让不同水平的实现跑出来有肉眼可见的差距，你要是所有 agent 都跑 100 分，那说明题出得不够狠。

4.2 行为审计：每一次工具调用都要被记录和复盘

"智能体行为审计"这个词听起来很重，其实是每个严肃项目都应该具备的基本功：把智能体的每一步动作、每一段输入输出、每一次工具调用参数、每一次失败原因都完整记录成 trace，并且保证事后可以一键回放。

为什么要做行为审计？因为智能体的错误往往不是显式的崩溃，而是"它做了一串看似合理但方向错了的动作"，最后浪费了大量时间。没有 trace，你根本不知道它在哪一步拐错了弯。我见过很多团队调 prompt 调几周没有进展，一查 trace 发现是工具返回结果被截断了，模型根本看不到关键报错——这种问题不靠审计你怎么都猜不到。

审计还要跟权限结合。智能体手里拿的密钥、能访问的数据范围、可执行的命令白名单，都要做到按最小权限原则配置。行为审计不是说记录就给安全感，而是要能借此发现问题并收紧权限。

4.3 多智能体协作里的死锁与令牌陷阱

承接前面聊的多智能体协作，这里补充两个实战中必踩的坑。

第一个坑是"死锁式空转"。两个子智能体互相把观点发给对方，看起来在"协作"，实际上每次回复都是几千 token 的客气话，一轮轮推进不了一点实质内容。要解决这个问题，最好的办法是给每个子智能体设置严格的输出协议：必须返回结构化结果，必须附带"本次是否完成、能否进入下一步"的状态位。没有状态位的协作，说白了就是互相甩废话。

第二个坑是 token 账单暴增。多智能体模式下，每个子智能体都要把共享上下文重新读一遍，一个任务动不动就吃掉几百万 token。我常用的优化手段有三条：尽量缩小共享上下文的颗粒度、把历史信息做摘要后再传给下一个智能体、以及能用单智能体跑完的简单任务绝不拆成多智能体。记住，多智能体的架构复杂度是要用真金白银置换的。

4.4 LLM 智能体自主容错控制的工程清单

这部分我直接给一份可以抄作业的清单，都是我在实践里一遍遍验证过的东西：

• 所有模型调用加超时，推荐从 10 秒起步，根据模型响应速度动态调整。
• 所有工具执行加超时，尤其是 shell、网络请求这类不可控操作。
• 有限重试机制：同一策略最多重试两次，第三次必须换策略或者上报人工。
• 幂等设计：同一动作重复执行不能产生副作用，比如"写文件"操作要能覆盖而非追加混乱内容。
• 熔断开关：连续失败达到阈值时，整个智能体要暂停并降级到人工接管模式。
• 状态快照：每一步都记录一个可回滚的快照，至少保留最近十个状态，方便人工回退。
• 代际改进：每次失败都要把原因和调整写入日志结构，供后续审计和分析使用。

这套清单的实质，是把智能体当成一个"操作真实系统的可疑进程"来对待。模型的能力决定了智能体的上限，但容错控制决定了它能不能站上生产环境。

5. 实操落地：用 Python 自建一个"修 bug"编程智能体

概念辨析聊完了，最后我用一个最小可复用的例子，带你完整走一遍编程智能体的搭建过程。这个项目不依赖任何重量级平台，用 Python 就能驱动起来，也能帮你把前面几章的概念和真实代码一一对上。

5.1 场景设定与架构选型

我设定一个非常典型的任务：项目仓库里有一段测试代码失败了，智能体要定位原因、修复代码、跑通测试。这几乎能代表编程智能体最核心的使用场景。

架构方面我采用最简单的循环式，不加多智能体。外层循环用 Python 代码实现，模型负责在每个循环里做决策。你完全可以用一个不超过一百行的while循环起步，等业务复杂度上来再迁移到 LangGraph 之类的框架。选型逻辑很简单：起步阶段脚本越少越好，你首要打磨的是循环逻辑和工具契约，而不是框架本身的编排能力。

5.2 工具契约与主循环设计

我设计了四个工具：read_file(path)、write_file(path, content)、run_command(cmd)和search_code(keyword)。每个工具函数都会返回一个固定的结构体：

def run_command(cmd): try: result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=30) return {"status": "success", "stdout": result.stdout, "stderr": result.stderr, "exit_code": result.returncode} except subprocess.TimeoutExpired: return {"status": "timeout", "stdout": "", "stderr": "", "exit_code": -1}

主循环的核心逻辑如下：

max_turns = 8 turn = 0 task_done = False while not task_done and turn < max_turns: overview = build_context(workspace, tool_descriptions) decision = model.call( system="你是修bug助手，每一步必须返回 {action, target, reason}", messages=overview + [history] ) result = dispatch_tool(decision) history.append(record_trace(decision, result)) task_done = check_terminal(result, task_goal) turn += 1 if not task_done: escalate_to_human()

注意几个细节：max_turns直接限制最大轮数，防止死循环；主循环不把完整历史全塞进去，而是定期让模型把历史压缩成摘要；每轮返回结构都落进history，这是行为审计的基础数据。

5.3 让"反馈"真正闭环的三个技巧

第一个技巧：命令输出只截取关键片段，别把整个日志塞进上下文。比如传给模型的 stderr 我只保留最后 80 行，再附上退出码。模型不需要看完整 5000 行的日志也能定位问题，但上下文被塞爆却会实实在在伤害它。

第二个技巧：强制 model 输出工具调用原因。即使你的工具名称很清楚，我也建议要一个reason字段解释为什么调用这个工具。它看似多余，实则在排查时价值巨大——你一眼就能看出模型是基于推测还是基于证据在行动。

第三个技巧：把"测试通过"写进终止条件。不是模型说要结束就能结束，而是当run_command("pytest -q")返回成功时，循环才真正终止。模型可能会误判，但工具执行的退出码不会。终止条件永远以外界反馈为准，这是编程智能体工程的铁律。

5.4 这些坑，我替你踩过了

第一个坑是模型"假装成功"。它修完代码后不看测试结果直接告诉你搞定了。解法就是我上面说的终止条件：只有工具真实返回成功，才算成功。

第二个坑是上下文膨胀。修到第五轮，历史里已经堆了十几次文件读取、命令输出，模型开始答非所问。我的做法是：每三轮做一次压缩，把前面的决策与结果摘要成两三句话，同时保留最近的完整一轮。

第三个坑是命令越权。给run_command挂在项目根目录下，并且用cwd限制在仓库范围，必要时直接在沙箱容器里跑整个智能体。记住一个原则：智能体能执行命令，本质上等价于把键盘交给了一个随机程序，权限必须做最小化。

第四个坑是重试逻辑不区分"失败类型"。网络超时可以重试，编译失败重试同样命令则毫无意义。失败分类要写清楚，同一动作的重试还是换策略，由失败类型决定。

6. 写在最后：能力是表象，闭环才是本质

做这个系列的过程中，我越来越觉得"智能体"这个词最大的问题不是太复杂，而是太廉价。市场上随便一个带 function calling 的 demo 都敢叫智能体，导致真正做工程的人反而被概念牵着走。

我个人在实操中的体会可以浓缩成一句话：判断一个系统是不是智能体，不看你用了多少高级词汇，只看它有没有形成"感知—决策—行动—反馈"的自主闭环。能力再强的模型，如果只是单轮问答，那依然只是个问答器；能力一般的模型，只要套上可靠的循环和严格的反馈机制，也能在真实环境里解决实际任务。

如果你正打算从零搭建自己的第一个智能体，我的建议是先别管那些花哨的框架和平台，拿出纸笔画出四件事：谁来感知环境、谁来规划步骤、谁来执行动作、谁来处理反馈。把这个闭环想清楚，哪怕第一版代码只有五十行，它也比那些架构画得天花乱坠却跑不出真实结果的方案靠谱得多。

下一期我大概率会接着写编程智能体的上下文管理和记忆压缩策略，这是目前让很多项目卡壳的深水区。这篇里提到的所有工具契约和审计思路，到那期会继续派上用场。