> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/01-thinking/agent-as-exoskeleton.md).

# Agent 不是队友，是外骨骼

## 问题：错误的心智模型

把 agent 假设成"不同的人"，会产生一种幻觉：

> 我只需要分工、协调、检查输出——就像管理一个团队。

这个比喻有一个根本性的破绽。

真实的团队成员有自己的判断力、经验和主动性，可以弥补老板的认知盲区。Agent 不行。它只能放大你已有的判断，无法超越你的理解框架。

***

## 核心结论：不要先给 Agent 定义角色

使用 agent 时，第一反应不应该是：

> 你现在扮演一个资深架构师。

而应该是：

> 我想解决什么问题，为什么要解决，已有约束是什么，什么结果算完成，哪些地方需要先问我。

Agent 不是固定岗位，而是通用执行系统。真正限制它的，不是角色名称，而是你给出的目标、上下文、工具权限和完成标准。

角色提示仍然有用，但它只是压缩表达的一种方式。比如"你是资深架构师"可以快速暗示它关注边界、风险、演进成本。但如果只给角色，不给目标和判断标准，agent 仍然会在模糊空间里自信推进。

所以，和 agent 协作的核心能力不是"会给它设定身份"，而是"会把自己的想法说清楚"。

> Agent 不是替你拥有想法的人，而是帮你把想法完成的人。

***

## 原因：老板的上限就是团队的天花板

| 你能做到的       | Agent 才能做到的 |
| ----------- | ----------- |
| 清晰定义问题      | 给出正确方向的解决方案 |
| 识别输出的质量     | 输出才真正有用     |
| 知道什么时候结果是错的 | 才不会被错误结果误导  |
| 理解任务的边界和风险  | 才不会产生危险的自动化 |

你看不出问题，agent 就会自信地犯错并一路推进。

这不是 agent 的缺陷，是它的本质：它在你设定的边界内执行，而边界的质量取决于你。

***

## Agent 的核心结构

理解 agent，不能只看模型本身。更准确的结构是：

```
Agent
  ├── Goal（目标）
  ├── LLM（思考）
  ├── Tools（执行）
  ├── Memory（记忆）
  └── Loop（循环）
```

其中最关键的分界不是"模型有多聪明"，而是它是否能在目标约束下持续观察、决策、行动、再观察。

很多 agent 框架最终都会落到同一个循环：

```
while not done:
    observe()
    think_with_llm()
    act_with_tools()
    observe_result()
    decide_if_done()
```

也就是：

```
Observe
  ↓
Think（LLM）
  ↓
Act（Tool）
  ↓
Observe
```

这个闭环，是 agent 和普通 chat 的根本区别。

***

## 最简 Agent

一个最小 agent 甚至可以简化成：

```
while True:
    prompt = build_context()
    result = llm(prompt)
    if result.tool:
        execute_tool(result.tool)
    else:
        break
```

在这个结构里：

* LLM 是大脑，负责判断下一步
* Loop 是驱动器，负责让判断持续发生
* Tool 是手，负责把判断变成外部动作
* Memory 是上下文延续机制，避免每一轮都从零开始
* Goal 是停止条件和方向约束

所以说：

> Agent = LLM + Loop

这个说法在极简层面是成立的。但它只是最小定义，不是完整工程定义。真正可用的 agent 更接近：

> Agent = Goal + LLM + Tool + Memory + Loop

***

## 为什么只有 LLM 不够

普通 chat 的结构是一次性调用：

```
用户
  ↓
LLM
  ↓
回答
```

一轮结束。

例如用户说："帮我查询天气。"如果模型没有工具，它只能解释、推测或拒绝，不能真的查询。

Agent 的结构不同：

```
用户
  ↓
LLM 判断需要什么信息
  ↓
调用天气 API
  ↓
获取结果
  ↓
LLM 总结
  ↓
返回
```

这里出现了三个新增能力：

* **Tool**：能影响外部世界，而不是只生成文本
* **Loop**：能根据工具结果继续判断，而不是一轮结束
* **Goal**：知道什么时候该停，而不是无限执行

没有 Tool，模型不能行动。没有 Loop，工具调用只是一次函数调用。没有 Goal，循环没有方向，也没有可靠的完成标准。

***

## Claude Code 的本质

Claude Code 这类工具，本质上就是把代码任务放进 agent loop：

```
Loop
  ↓
Claude
  ↓
Tool Use
  ↓
文件系统 / Shell / Git / Search
```

当你说"修复这个 bug"时，它不是只回答一次，而是在循环中推进：

```
读代码
  ↓
分析
  ↓
搜索引用
  ↓
修改文件
  ↓
运行测试
  ↓
根据结果继续修改或结束
```

一个看似简单的任务，背后可能循环几十轮。真正产生价值的，不只是单次模型回答，而是模型、工具和反馈结果之间的持续闭环。

***

## 为什么现在重点转向 Agent Loop

早期模型能力跃迁很大，单纯换模型就能带来明显收益。随着主流大模型能力逐渐接近，继续提升效果的关键开始转向系统层：

* 更好的 Loop：能否稳定推进，而不是跑偏
* 更好的 Tool：能否可靠行动，而不是只会解释
* 更好的 Memory：能否保留关键上下文，而不是每轮失忆
* 更好的 Planning：能否拆解任务、设置检查点、控制风险

也就是说，竞争焦点从"更大的模型"转向"更好的 agent 系统"。

从 Codex 的结构看，也可以这样理解：

| 概念       | 对应含义         |
| -------- | ------------ |
| Goal     | Agent 要完成什么  |
| Loop     | Agent 怎么持续运行 |
| Skill    | Agent 会什么能力  |
| Memory   | Agent 记住什么   |
| Tool     | Agent 能操作什么  |
| Computer | Agent 在哪里执行  |

因此，agent 和普通 ChatGPT 的本质区别，不在于它用了哪个模型，而在于它是否具备持续决策循环。没有 Loop，本质上仍然只是一次性的 LLM 调用。

***

## 判断标准：正确的心智模型

**Agent 是你认知能力的外骨骼，不是独立的队友。**

外骨骼放大你的力量，但力量的方向和判断由你决定。骨骼本身不产生判断。

这意味着：

* **不要问** "这个 agent 能做什么"，**要问** "我能验证什么"
* **不要期待** agent 发现你没有发现的问题，**要期待** 它更快地执行你已经想清楚的事
* **不要用** 增加 agent 数量来弥补自己对任务的不理解

***

## 如何把想法交给 Agent

如果 agent 的本质是 Goal + LLM + Tool + Memory + Loop，那么它首先不是"一个角色"，而是一个通用执行系统。

更好的输入方式，是把想法结构化：

* **目标**：我要完成什么
* **背景**：为什么现在要做
* **约束**：哪些不能改，哪些必须遵守
* **判断标准**：什么结果算好，什么结果算错
* **授权边界**：哪些可以直接做，哪些需要确认
* **反馈方式**：希望它边做边汇报，还是完成后一次性总结

这带来一个新的结论：

> 不要急着给 agent 定义角色。 先学会把你的想法、判断和边界说清楚。

***

## 实践含义

想提升 AI 工程的输出上限，根本路径是提升自己的判断力，而不是增加 agent 层数。

更多的 agent、更复杂的编排、更精细的分工——这些都有价值，但它们是乘数，不是基数。基数是你自己理解问题的深度。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/01-thinking/agent-as-exoskeleton.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.