Appearance
搞定 Agent 六大支柱：今天出个 Manus 明天出个 OpenClaw，你到底应该学什么？
最近这大半年，搞技术的朋友应该都有一个感受：Agent 这个词，铺天盖地。
Claude Code 出了 /loop 定时任务，OpenClaw 的 GitHub star 飙到了 25 万但紧接着爆出了高危 RCE 漏洞，Cursor 搞出了 Automations 和自托管 Agent，OpenAI Codex 出了桌面客户端……社交媒体上，每个产品都说自己是"真正的 AI Agent"，每篇文章都在教你"如何构建 Agent"，信息量大到让人窒息。
有不少读者朋友跟我说过类似的话：
"我知道 Agent 很重要，但我不知道从哪学起。感觉每天都在出新东西，学不完。"
说实话，我特别理解这种状态。因为我也曾经经历过。
不过这些年下来，自己也做了一些 Agent 产品，也比较深入地研究过 Claude Code、OpenClaw、Manus 这些项目的原理和设计，踩了不少坑之后，我慢慢有了一个比较清晰的认知：
这些产品表面上形态各异，底层全在解决同一组问题。
而且这组问题的数量，远比你想象的少。
一次 Agent 调用背后发生了什么
我用一个你可能每天都在做的场景来说明。
假设你在终端里跟 Claude Code 说：
帮我把 src/utils.ts 里的 formatDate 函数重构一下，用 dayjs 替换 moment然后你按下回车。从这一刻开始，到 Claude Code 跟你说"搞定了"，中间发生了什么？
第一件事：它得决定先做什么。
Claude Code 不会上来就改代码。它会先"想"一下：我需要先读一下 utils.ts 看看 formatDate 长什么样，然后看看 package.json 里有没有 dayjs，没有的话要装一下，然后再改代码，改完跑一下测试……
这个"想一步、做一步、看一步"的循环，就是 Agent Loop。它是 Agent 的心跳——没有这个循环，AI 就只是一个问答机器。
第二件事：它得能读文件、跑命令。
光"想"没用，得有手。Claude Code 需要调用 Read 工具读文件、调用 Bash 工具跑 pnpm add dayjs、调用 Edit 工具改代码。
这些工具的定义、调度、权限管理、并发控制，组成了 Tool System。它是 Agent 的手脚——没有工具，Agent 就是个只会说不会做的嘴炮。
第三件事：它得记住前面做了什么。
假设这个重构涉及 15 个文件，Claude Code 改到第 10 个文件的时候，它需要记住前面 9 个文件改了什么、用了什么模式、有没有遇到什么坑。但上下文窗口是有限的——前面的信息太多了，塞不下了怎么办？
这就是 Context Engineering，上下文工程。它是 Agent 的大脑供血系统——决定大脑能获得多少养分、处理多少信息。这块我认为是整个 Agent 开发里最被低估、也最有含金量的部分。
第四件事：它得记住你是谁。
你上次跟 Claude Code 说过"这个项目用 pnpm 不要用 npm"，它会记住。下次你开一个新的会话，它还能记得。
这是 Memory 系统——跨会话的长期记忆。和 Context Engineering 不同，Context 管的是单次会话内的信息，Memory 管的是跨会话的持久化。
第五件事：复杂任务，一个 Agent 搞不定。
如果你让 Claude Code 探索一个几万行的代码库，它可能会 fork 出一个子 Agent，让子 Agent 在干净的上下文里去探索，探索完把结果压缩成一两千 token 的摘要传回来。这样主 Agent 的上下文不会被撑爆。
这就是 Multi-Agent——不是为了"分角色"搞什么 PM + 设计师 + 开发者的 cosplay，而是为了分隔上下文。
第六件事：权限、Hook、重试、优雅退出……
Agent 要跑 rm -rf 的时候，谁来拦？API 挂了怎么重试？用户按了 Ctrl+C 怎么优雅退出？模型陷入死循环怎么检测？
这些"包裹在模型外面"的工程系统，就是 Harness Engineering。它是 Agent 的骨架——模型再强，没有一个好的骨架，也跑不起来。
六大支柱
你看，就这一次看似简单的工具调用，背后牵扯了六个大的系统：
| 支柱 | 一句话 | 人体类比 |
|---|---|---|
| Agent Loop | 想一步、做一步、看一步的循环 | 心跳 |
| Tool System | 读文件、跑命令、调 API | 手脚 |
| Context Engineering | 管理有限的上下文窗口 | 大脑供血 |
| Memory | 跨会话的长期记忆 | 长期记忆 |
| Multi-Agent | 拆任务、分上下文 | 团队协作 |
| Harness Engineering | 权限、重试、Hook、生命周期 | 骨架 |
记住这六个词。 后面不管出什么新的 Agent 产品、新的框架、新的论文，你都可以用这六个维度去拆解它。它在 Agent Loop 上做了什么创新？Context Engineering 怎么处理的？工具系统是什么设计？
这就是为什么我说"学 Agent 不要追产品、热点，要学底层问题"。产品会过时，但问题不会。
六大支柱，每个都有多深？
你可能觉得，这六个词听起来挺简单的嘛，有什么好学的？
那我给你展开聊聊，你感受一下每个支柱背后的水有多深。
Agent Loop：不只是个 while 循环
最简单的 Agent Loop 就是一个 while(true) { think → act → observe } 循环。10 行代码就能写出来。
但实际跑起来你会发现一堆问题：
模型说到一半被截断了怎么办？Claude Code 的做法是 3 次递进恢复——第一次把 max_tokens 设成 8192 希望它能说完，不行就升到 64K，再不行就注入一条"你的输出被截断了，请继续"的消息。超过 3 次就放弃。
Agent 陷入死循环怎么办？OpenClaw 设计了 4 种检测器：同一个工具反复调用（Generic Repeat）、无进展的轮询（Known Poll）、两个工具交替调用（Ping-Pong）、全局熔断（30 次重复强制停止）。不是一种检测就够了，实际场景中循环的模式五花八门。
API 挂了怎么办？Claude Code 有三层重试：内层 API 级重试（最多 10 次指数退避）、中层流式失败降级为非流式、外层快速模式失败降级为标准模式。OpenClaw 更夸张——重试预算最多 160 次，还有各种模型 Provider 相互兜底，具体我们先不展开了，后面的课程会展开。
就一个循环——Agent Loop，展开来讲可以讲很多篇。
Tool System：工具越多越不准
你可能觉得工具系统就是定义几个函数让模型调嘛，有什么难的。
实际上，工具数量一上去，问题就来了。10 个工具以内，模型选择准确率 > 95%；30 个工具，降到 ~85%；50 个以上，不做特殊处理就是灾难。
怎么解决？Claude Code 用了一个叫 Deferred Tool Loading 的设计——初始 prompt 里只放工具名和一句话描述，不放完整的 JSON Schema。模型需要用某个工具的时候，先通过 ToolSearch 按需加载完整定义。效果：初始 prompt 瘦身 30-40%，缓存命中率大幅提升。
Manus 走了另一条路——干脆只保留不到 20 个原子工具，复杂操作全部通过写脚本放 sandbox 里跑。工具定义只占 3K token，而不是 30K。
还有一个容易忽略的问题：工具定义一旦改了，后面所有的 KV Cache 全部失效。 这意味着你不能动态增删工具——看起来省了 token，实际上缓存失效的成本可能是 10 倍。Manus 的做法是 "Mask Don't Remove"：不删工具定义，只标记哪些不可用，并通过比较巧妙的方式来限制模型的 Action Space，后续我们也会好好拆解。
Context Engineering：最被低估的护城河
这一块我认为是整个 Agent 开发里技术含量最高的部分。
一个数据帮你感受一下：一个典型的 Agent 任务，50 次工具调用，每次平均 2000 token 的结果，光工具输出就是 10 万 token。再加上 system prompt、工具定义、对话历史——200K 的窗口说满就满。
而且上下文不是越长越好。学术界有一个叫 "Lost in the Middle" 的现象：模型对上下文头部和尾部的信息注意力最强，中间的内容会被逐渐忽略。你往上下文里塞的东西越多，模型对中间信息的"记忆力"就越差。
所以上下文管理的核心不是"怎么塞更多"，而是怎么让模型在有限的注意力预算内看到最关键的信息。
我们在课程里会用五个维度来拆解 Context Engineering：
| 维度 | 做什么 |
|---|---|
| Offload（卸载） | 把信息搬到上下文之外——文件系统、sandbox、脚本 |
| Reduce（压缩） | 就地缩小（Compaction）或用摘要替换（Summarization） |
| Retrieve（检索） | 从外部按需取回——RAG、文件读取、ToolSearch |
| Isolate（隔离） | 拆成多个独立上下文——Multi-Agent |
| Cache（缓存） | 复用已有计算结果——KV Cache、Prompt Cache |
有意思的是，行业对这五个维度并没有共识。Manus 重度使用 Offload 和 Cache，但不太鼓励压缩——因为信息丢失风险太大。没有银弹，每个维度都有 trade-off。
还有一个点：压缩不等于删除。 好的上下文管理是可恢复的——信息不是真丢了，只是暂时移出了模型的视野。
Memory：简单方案反而更好
跨会话记忆听起来应该很复杂——向量数据库、语义检索、embedding 模型……
但 Claude Code 用的方案简单到让人意外：就是一个 MEMORY.md 文件。
模型自己用 Write 工具把值得记住的信息写进去，下次会话开始的时候读回来。没有向量数据库，没有 embedding，就是纯文本文件。
反过来，OpenClaw 走的是比较重的路线——SQLite + 向量混合检索，BM25 关键词权重 30% + 向量权重 70%，还有 MMR 去重和时间衰减。
哪个更好？取决于你的场景。Claude Code 面对的是单用户、记忆量不大的场景，文件方案简单可调试，人类可直接编辑。OpenClaw 面对的是多用户、大量记忆的场景，需要语义搜索能力。
没有最好的方案，只有最合适的方案。 这个判断力，比学会某个具体技术更重要。
Multi-Agent：不是分角色，是分上下文
市面上很多 Multi-Agent 的教程都在教你搞"角色扮演"——一个 Agent 当 PM，一个当开发，一个当测试。
但真的，业界用的 Multi-Agent，核心价值根本不在这里。
Manus 的联合创始人 Peak 说了一句很精辟的话："人类按角色组织是因为认知限制。LLM 不一定有这些限制。"
子 Agent 的主要目标不是按角色分工，而是隔离上下文。 让每个子 Agent 在干净的窗口里工作，不被其他任务的信息污染。
Claude Code 的子 Agent 设计就是这个思路——Explore Agent 去探索代码库，在自己的上下文里可以读几万 token 的文件，最后只给父 Agent 返回一两千 token 的摘要。父 Agent 的上下文保持干净。
还有一个更硬核的场景：Claude Code 的 Worktree 隔离。子 Agent 在一个独立的 git worktree 里工作，文件系统都是隔离的。做完了再 merge 回来。这才是生产级的 Multi-Agent。
Harness Engineering：模型外面那层壳
最后这个，可能是最不性感但最重要的。
Harness 翻译过程可以叫“壳”，也可以叫环境，它的设计可能比模型选择的影响更大。
举个具体的例子。OpenClaw 今年爆出了 CVSS 8.8 的高危 RCE 漏洞，3 万多个实例受影响，800 多个恶意 Skill 混进了 ClawHub 市场。你猜猜是啥 原因？默认没开认证。
这不是模型的问题，是 Harness 的问题。权限系统设计得不够严格，一个漏洞就能让整个 Agent 变成攻击工具。
Claude Code 在这方面做得很细：6 种权限模式、Bash 命令专用风险分类器、危险操作模式检测（rm -rf /、fork bomb、sudo）、连续被拒会自动降级为手动确认。还有 14 种 Hook 类型让用户能在不改源码的情况下定制行为。
这些东西虽然看起来不够酷炫，但没有它们，Agent 就是一个随时可能失控的定时炸弹。
学的顺序很重要
这六个支柱不是平行的，它们之间有依赖关系。我建议的学习路径是从内到外：
- Agent Loop（心跳）：先理解 Agent 的最小可运行单元
- Tool System（手脚）：Agent 能"做事"了，你才能观察后面的问题
- Context Engineering（供血）：Agent 跑起来之后，上下文爆了怎么办？这是深水区的入口。
- Memory（记忆）：单次会话、跨会话，上下文记忆怎么来管理？
- Multi-Agent（协作）：一个 Agent 不够用，怎么拆成多个？
- Harness Engineering（骨架）：上面都搞定了，怎么包成一个生产级系统？
每一层都建立在前一层的基础上。你不理解 Agent Loop，就没法理解为什么 Context Engineering 这么重要；你不理解 Context Engineering，就不理解为什么 Multi-Agent 的核心价值是"分上下文"而不是"分角色"。
这门课怎么组织的
说白了，这门课就是沿着上面这条路径，一层一层往上搭。
每一篇我都会从一个生产环境里真实会遇到的问题出发——不是编一个教科书式的例子，而是你做 Agent 真的会踩到的坑。然后去看 Claude Code、OpenClaw、Manus 这些百万级用户的 AI 产品是怎么解决这个问题的。最后提炼出可复用的设计原则。
几个你可能关心的问题：
需要什么基础？
有前端或全栈开发经验就行。TypeScript 能看懂，命令行能用，API 调过就够了。不需要机器学习背景、不需要 AI 背景。下一篇我会专门讲做 Agent 需要了解的大模型底层知识，不多，但必须知道。
学完能做什么？
不管市面上出什么新的 Agent 框架、新的产品，你都能快速看懂它的架构，知道它在六大支柱的哪些维度上做了什么取舍。你也能自己从零搭一个 Agent 系统——不是调 LangChain 的 API，是真正理解每一个工程决策背后的 why。
根据我的调研，学习这门课程大部分都是命中了下面这些诉求：
- 原来的技术栈快过时了，想要在 AI 时代提升自己，增强自己技术上的能力，提升竞争力
- 公司业务有需要，agent 开发是一个刚需
- 想要找工作面试，需要系统的资料来学习
如果你有类似的诉求，那这门课程还是适合你来学习的。
跟别的 Agent 课有什么不同？
大部分 Agent 课教你用某个框架——"用 LangChain 和 Langraph 搭一个 Agent"、"用 Pi 写一个 Agent"。框架一更新，课就过时了。
这门课不教你具体怎么用框架，而是教你理解框架背后在解决什么问题。我会带你从 Claude Code、OpenClaw、Manus 等等底层设计原理的角度跟大家拆解，让你们彻底搞明白到底怎么才能驾驭一个真实的 agent 系统。
温馨提示：安装 App 并开启通知
课程平台支持 PWA（渐进式 Web 应用），安装后拥有原生 App 体验，包括桌面图标、离线访问、每日复习提醒和课程更新推送。
强烈建议安装并开启通知，这样你能收到复习提醒和课程更新通知，帮助巩固所学知识。
iOS
- 用 Safari 打开 https://sitor.ai （仅 Safari 支持，Chrome/Firefox 不行）
- 点击底部工具栏的 分享按钮（方框 + 向上箭头图标）
- 滑动菜单找到 「添加到主屏幕」，点击确认
- 从主屏幕打开 Sitor，进入后点击右上角 设置（齿轮图标） → 「开启通知」
- 在弹出的系统权限对话框中点击「允许」
桌面（Chrome / Edge）
- 打开 https://sitor.ai
- 地址栏右侧会出现安装图标（或页面顶部弹出安装横幅），点击安装
- 安装后点击设置 → 「开启通知」 → 允许权限
注意：目前推送通知支持 iOS（需添加到主屏幕）和桌面浏览器（Chrome / Edge），安卓暂不支持。
后面的路
然后我们就正式进入 Agent 的世界。从一个 while(true) 循环开始，一步一步搭起来。