阅读时间：约 10 分钟
前置知识：了解 LLM 是什么；知道 OpenAI 的函数调用；能跑通一个简单的 API 请求
“我不再 prompt Agent，我设计 Loop。”
Claude Code 的负责人和 OpenClaw 的负责人先后说了几乎同一句话。当时我没听懂这句话的分量。
后来我写了十几个 Agent，踩了足够多的坑，才真正理解：
Agent 的核心不在模型有多聪明，而在你如何设计它的工作循环。而在设计循环之前，你首先要搞清楚——什么不是 Agent。
误解一：能调工具的就是 Agent
最常见的定义：LLM + 函数调用 = Agent。
这个定义的问题——它把一个能力当成了一个系统。
Function Calling 确实是 Agent 体系中最基础的技术组件。但"能调用工具"只是 Agent 的第一层积木。
一个真正能称为 Agent 的系统，需要同时满足：
- 感知：能理解上下文、识别任务状态、判断工具调用的时机和参数
- 决策：根据感知结果，做出多步推理（不是单次判断，而是一连串的判断）
- 执行：调用工具、处理返回值、判断是否继续还是结束
- 闭环：上述三个环节形成可循环的机制，不是跑一次就停
🤔思考一下：你现在的项目中，哪个环节最容易断掉？感知、决策、执行，还是判断是否继续？
正确的定义：
Agent 是一个具备感知-决策-执行闭环的自主系统。它能在不确定环境中，通过多步推理和工具交互，完成一个目标。
这个定义里最关键的词是**“闭环”**。没有闭环，只有 LLM 的一次性调用——你叫它"自动化脚本"更合适。
📌本章要点：Agent ≠ 单次 LLM 调用。Agent = 感知 + 决策 + 执行 + 闭环。没有闭环，只是自动化脚本。
刚才我们搞清楚了"什么不是 Agent"。但搞清楚之后，你面临一个更大的问题：你真正需要搞清楚的是模型的边界，而不是模型能做什么。
误解二：Agent 什么都能做
这是比第一个误解更危险的错觉。
很多初学者在写完第一个"能跑起来"的 Agent 后，会立刻开始往上加功能：
- “能不能让它自己写代码？”
- “能不能让它自己调试？”
- “能不能让它自己部署？”
每多一个"能不能"，你就离过度工程化更近一步。
模型能力 vs 工程边界
Agent 的能力边界由两部分组成：
模型自身能力（不需要工程处理）：
- 文本理解、推理、生成
- 基于上下文的判断
- 多轮对话中的上下文记忆
超出模型能力（必须工程处理）：
- 确定性结果（“这个 Bug 的根因”——模型会说"可能"）
- 精确状态（“文件第 37 行有一个 bug”——模型会数错）
- 持久化状态（“我上次看到的那个 API 文档”——模型不记得）
- 外部世界交互（“执行一个不可逆的操作”——模型不知道后果）
🤔思考一下：你手头的项目里，有哪些需求是模型"天然做不到"的？不是"做得不好"，而是"根本做不到"。
一个真实的踩坑案例
我见过一个"智能客服"Agent 的设计方案：
- 接收用户消息
- LLM 理解意图 → 从知识库检索
- LLM 生成回复
初看合理。但实际运行时出现了一个致命问题：当知识库检索不到相关信息时，Agent 没有任何"不知道就说不知道"的兜底机制，而是继续基于有限的信息编造答案。
这不是模型能力不够，是工程边界不清。正确的做法是加一道"判断置信度"的门——如果检索结果与用户问题的相关性低于阈值，不生成回复，直接转人工。
📌本章要点：模型能力 ≠ 工程系统能力。确定性任务需要工程兜底。每个环节设兜底——感知有置信度、决策有阈值、执行有验证。
刚才我们说了模型能力的边界。接下来看另一个常见的过度设计——你以为它需要多 Agent，其实单 Agent 就够了。
误解三：多 Agent 协作 = 好 Agent
当你理解了"什么不是 Agent"之后，下一个陷阱就是：“既然单 Agent 不够，那上多 Agent！”
这是 AI 社区最流行的幻觉之一。多 Agent 不是答案，它只是把问题从"一个 Agent 搞不定"变成了"多个 Agent 的协调问题更难解决"。
什么时候该用多 Agent？
只有同时满足以下条件时才考虑：
- 任务可以明确拆分为独立的子任务（不是"看起来可以拆"）
- 子任务之间有清晰的数据流转关系（不是"大概这样传"）
- 子任务之间的依赖关系不需要频繁回溯（不是"做到一半要改前面"）
否则，优先用单 Agent。简单不是妥协，是工程直觉。
📌本章要点：多 Agent 不是升级，是复杂度升级。能不用就不用。先实现一个能用的单 Agent，然后再考虑是否需要多 Agent。
Agent 的工程边界——决策循环图
现在你已经知道"什么不是 Agent"了。接下来要看的是：Agent 工程中，哪些事是模型该做的，哪些事是工程该做的。
这张图描述了一个典型 Agent 的决策循环，以及每一步的工程边界：
关键边界标注：
| 环节 | 模型负责 | 工程负责 |
|---|---|---|
| 感知 | 理解意图、提取上下文 | 设定感知阈值、过滤噪声 |
| 决策 | 生成执行计划、推理 | 置信度判断、兜底策略、安全约束 |
| 执行 | 调用工具、生成参数 | 幂等性保证、错误分类、重试策略 |
| 判断 | 是否继续/结束的判断 | 超时控制、最大循环次数、停止条件 |
📌本章要点：模型负责"做什么"，工程负责"做到什么程度"。先画你的 Agent 决策循环图，再标注每个环节的边界。
🤔思考一下：对照这张图，你当前实现的 Agent，哪个环节的边界是模糊的？比如"决策层该由模型决定，但实际写成了工程判断"？
最强 Agent 的真相：模型是引擎，Harness 是整辆车
Claude Code 的源码被泄露后，社区对它的架构分析揭示了几个关键点：
- 核心竞争力不是模型本身，而是"模型周围的精密控制系统"——也就是 Agent 工程中的Harness
- 上下文管理采用三级压缩流水线：微压缩 → 绘画记忆压缩 → 完整压缩。核心工具启动时加载，扩展工具按需加载
- 安全与约束通过分类器、权限模式、HOOX 系统实现，规则一旦编码，在所有循环中机械式执行
📌本章要点：模型是引擎，Harness 是整辆车。没有好的 Harness，再强的引擎也跑不快。系统设计优先于模型选择。
过渡引导语：
到这里，我们从"什么不是 Agent"聊到了"Agent 的工程边界"，最后看了一家最强编码 Agent 的架构真相。你可能觉得——这离我自己写一个能跑的 Agent 还差得远。别急。下一篇，我们从一个最简单的 Agent 开始。
总结：读完这篇，你应该带走这几件事
本文围绕五个核心概念展开，建议你读完后再回顾一遍：
- Agent 是什么：感知 + 决策 + 执行 + 闭环，缺一不可。没有闭环的系统不是 Agent。
- 什么不是 Agent：单次 LLM 调用、Workflow 模板、多 Agent 堆砌——这些都不是 Agent。
- 模型边界：模型负责理解和推理，工程负责确定性、持久化和不可逆操作。
- 多 Agent：不是升级，是复杂度升级。先做好单 Agent，再考虑多 Agent。
- Harness：模型是引擎，Harness 是整辆车。系统设计优先于模型选择。
🤔思考一下：你现在觉得自己在哪个阶段？是"还在理解什么是 Agent"、“能跑起来但不知道边界”、还是"知道边界但不知道怎么设计"？带着这个问题的答案，进入下一篇。
思维导图
- 什么不是 Agent
- 三个常见误解
- 调工具 = Agent
- 一次调用不等于闭环
- 需要感知 + 决策 + 执行 + 闭环
- 什么都能做
- 模型能力不等于工程能力
- 确定性任务需工程兜底
- 多 Agent = 好 Agent
- 复杂度升级
- 能不用就不用
- 调工具 = Agent
- Agent 工程边界
- 感知层：意图识别和上下文提取 / 工程负责阈值过滤和兜底
- 决策层：生成执行计划 / 工程负责置信度和安全约束
- 执行层：工具调用和参数生成 / 工程负责幂等性和重试
- 判断层：是否继续和结束 / 工程负责超时和最大循环
- 最强 Agent 的真相
- Claude Code 源码分析
- 模型是引擎，Harness 是整辆车
- 上下文三级压缩
- 约束机械式执行
- 核心 Takeaways
- 先搞清楚边界再动手
- 单 Agent 做好再考虑多 Agent
- 系统设计优于模型选择
- 闭环才是 Agent 的底线
- 三个常见误解
下一篇预告
P02. Tool Use 实战：让 LLM 调用外部工具的 3 种模式
从 0 开始，写一个能跑起来的 Agent。代码量不到 50 行。
工具定义 → 绑定到 Chat Completion → 解析 Tool Call → 执行函数 → 提交 Tool Message
看完这篇，你会理解：为什么 Function Calling 是 Agent 的第一块积木，以及为什么它只是积木，不是整个房子。
🤔思考一下：读完这篇后，你对 Agent 的理解有没有被改变？或者你有踩过的坑想分享？在评论区告诉我。
