阅读时间：约 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 的设计方案：

1. 接收用户消息
2. LLM 理解意图 → 从知识库检索
3. LLM 生成回复

初看合理。但实际运行时出现了一个致命问题：当知识库检索不到相关信息时，Agent 没有任何"不知道就说不知道"的兜底机制，而是继续基于有限的信息编造答案。

这不是模型能力不够，是工程边界不清。 正确的做法是加一道"判断置信度"的门——如果检索结果与用户问题的相关性低于阈值，不生成回复，直接转人工。

📌 本章要点：模型能力 ≠ 工程系统能力。确定性任务需要工程兜底。每个环节设兜底——感知有置信度、决策有阈值、执行有验证。

---

刚才我们说了模型能力的边界。接下来看另一个常见的过度设计——你以为它需要多 Agent，其实单 Agent 就够了。

误解三：多 Agent 协作 = 好 Agent

当你理解了"什么不是 Agent"之后，下一个陷阱就是：“既然单 Agent 不够，那上多 Agent！”

这是 AI 社区最流行的幻觉之一。多 Agent 不是答案，它只是把问题从"一个 Agent 搞不定"变成了"多个 Agent 的协调问题更难解决"。

什么时候该用多 Agent？

只有同时满足以下条件时才考虑：

1. 任务可以明确拆分为独立的子任务（不是"看起来可以拆"）
2. 子任务之间有清晰的数据流转关系（不是"大概这样传"）
3. 子任务之间的依赖关系不需要频繁回溯（不是"做到一半要改前面"）

否则，优先用单 Agent。简单不是妥协，是工程直觉。

📌 本章要点：多 Agent 不是升级，是复杂度升级。能不用就不用。先实现一个能用的单 Agent，然后再考虑是否需要多 Agent。

---

Agent 的工程边界——决策循环图

现在你已经知道"什么不是 Agent"了。接下来要看的是：Agent 工程中，哪些事是模型该做的，哪些事是工程该做的。

这张图描述了一个典型 Agent 的决策循环，以及每一步的工程边界：

关键边界标注：

环节	模型负责	工程负责
感知	理解意图、提取上下文	设定感知阈值、过滤噪声
决策	生成执行计划、推理	置信度判断、兜底策略、安全约束
执行	调用工具、生成参数	幂等性保证、错误分类、重试策略
判断	是否继续/结束的判断	超时控制、最大循环次数、停止条件

📌 本章要点：模型负责"做什么"，工程负责"做到什么程度"。先画你的 Agent 决策循环图，再标注每个环节的边界。

🤔 思考一下：对照这张图，你当前实现的 Agent，哪个环节的边界是模糊的？比如"决策层该由模型决定，但实际写成了工程判断"？

---

最强 Agent 的真相：模型是引擎，Harness 是整辆车

Claude Code 的源码被泄露后，社区对它的架构分析揭示了几个关键点：

1. 核心竞争力不是模型本身，而是"模型周围的精密控制系统"——也就是 Agent 工程中的 Harness
2. 上下文管理采用三级压缩流水线：微压缩 → 绘画记忆压缩 → 完整压缩。核心工具启动时加载，扩展工具按需加载
3. 安全与约束通过分类器、权限模式、HOOX 系统实现，规则一旦编码，在所有循环中机械式执行

📌 本章要点：模型是引擎，Harness 是整辆车。没有好的 Harness，再强的引擎也跑不快。系统设计优先于模型选择。

过渡引导语：
到这里，我们从"什么不是 Agent"聊到了"Agent 的工程边界"，最后看了一家最强编码 Agent 的架构真相。你可能觉得——这离我自己写一个能跑的 Agent 还差得远。

别急。下一篇，我们从一个最简单的 Agent 开始。

---

总结：读完这篇，你应该带走这几件事

本文围绕五个核心概念展开，建议你读完后再回顾一遍：

1. Agent 是什么：感知 + 决策 + 执行 + 闭环，缺一不可。没有闭环的系统不是 Agent。
2. 什么不是 Agent：单次 LLM 调用、Workflow 模板、多 Agent 堆砌——这些都不是 Agent。
3. 模型边界：模型负责理解和推理，工程负责确定性、持久化和不可逆操作。
4. 多 Agent：不是升级，是复杂度升级。先做好单 Agent，再考虑多 Agent。
5. Harness：模型是引擎，Harness 是整辆车。系统设计优先于模型选择。

🤔 思考一下：你现在觉得自己在哪个阶段？是"还在理解什么是 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 的理解有没有被改变？或者你有踩过的坑想分享？在评论区告诉我。