Agent 的发展轨迹：从”会聊天”到”会干活”的四阶段演进

一句话总览：AI Agent 这几年的进化史，本质是包在大模型外面的”工程外壳”越做越厚的历史。从 Prompt Engineering → Reasoning/ReAct → Context Engineering → Harness Engineering，四个阶段不是替代关系，而是俄罗斯套娃式的层层包裹。

0. 给小白的总体画面感
1. 阶段一：Prompt Engineering（提示词工程）
2. 阶段二：Reasoning + ReAct（推理 + 行动）
3. 阶段三：Context Engineering（上下文工程）
4. 阶段四：Harness Engineering（外壳/挽具工程）
5. 关键洞察：四阶段是”俄罗斯套娃”，不是并列
6. Agent 演进的 4 个深层趋势
7. 拓展：你还需要知道的几个关键词
8. 给小白的入门路径建议
9. 与本知识库其他章节的关联
10. 职业视角：什么是 Agent 架构师

0. 给小白的总体画面感

把”大模型”（GPT、Claude）想象成一个 特别聪明、但被关在小黑屋里的天才大脑：

✅ 他知识渊博、会思考、会写文章
❌ 但他没有手、没有眼睛、没有记忆、走不出房间
💡 你想让他帮你”做事”（不是只回答问题），就必须给他配一整套装备：眼睛（看屏幕）、手（敲键盘）、笔记本（记东西）、工具箱（调用各种软件）……

这套包在大脑外面的装备，就叫 “Harness”（马具/挽具）。 Harness 这个词原本是套在马身上的”挽具”——缰绳、马鞍、马蹄铁。马本身有力气，但要拉车干活，得靠挽具把它”驾驭”起来。AI 的 Harness 也是同一个意思：把模型的能力”套出来”用。

Agent 的发展轨迹，就是 这套装备从”几乎没有”到”无比复杂”的进化史。

1. 阶段一：Prompt Engineering（提示词工程）

代表产品：ChatGPT（2022 年底） 核心命题：人怎么把话说清楚，让 AI 听懂

生动比喻

就像你雇了一个超级聪明、但耳朵不好的实习生。你让他写文章，得说清楚：

“写一篇 800 字的、面向小学生的、关于环保的、要有 3 个例子的作文”

说得越清楚，他做得越好。这门”怎么说话”的学问就是 Prompt Engineering。

阶段特征

维度	状态
主导方	人是主角，AI 是被动的”答题机器”
交互模式	一问一答，问完就忘
AI 自主性	几乎为零
工程复杂度	极低（写好提示词就够）

这个阶段没过时

后面的所有阶段，最里层都还是 Prompt。只是 Prompt 不再由人手写，而是由 Agent 自动拼装。

2. 阶段二：Reasoning + ReAct（推理 + 行动）

代表产品：AutoGPT、MetaGPT（2023 年） 核心命题：让 AI 自己思考、自己动手

生动比喻

还是那个实习生。以前你说”帮我查今天上海天气”，他只会瞎编（因为他不能上网）。现在你给他装了两个新本事：

Reasoning（推理）：让他在回答前 先在心里打草稿

“嗯，要查天气，得先打开浏览器，然后搜’上海天气’……”
ReAct（Reason + Act，边想边做）：让他 思考一步、动手一步、看结果、再思考——像侦探破案一样

ReAct 的经典套路

Thought（想）   → 我需要查上海天气
Action（做）   → 调用搜索引擎，关键词：上海天气
Observation（看）→ 返回："上海今天 22°C，多云"
Thought（再想） → 用户问的是天气，已得到答案
Action（再做） → 回复用户

这种”想-做-看-再想”的循环，是所有 Agent 的底层心跳。

阶段特征

维度	状态
主导方	AI 开始有自主性
交互模式	多轮循环、自主调用工具
主要痛点	容易跑偏、做着做着就”失忆”，不靠谱
工程复杂度	中等（要管理工具调用循环）

代表产品的不同侧重

AutoGPT：让 GPT 自己拆任务、自己执行，是最早的自主 Agent 探索
MetaGPT：让多个 AI 扮演不同角色（产品经理、工程师、QA）协作开发

3. 阶段三：Context Engineering（上下文工程）

代表产品：Manus、GenSpark、Cursor（2024 年） 核心命题：精确管理 AI 视野里的每一个 token

为什么会出现这个阶段

人们发现：AI 老是”失忆”、老是”答非所问”，根本原因是它每次能看到的内容是有限的（叫”上下文窗口”），而且看到太多也容易眼花、注意力涣散。

于是，新的功夫不再是”怎么问”，而是 “该让它看到什么、不该看到什么、按什么顺序看”。

生动比喻

那个实习生现在升级成助理了。但他桌子很小，一次只能摆 10 份文件。

❌ 不能把整个档案柜都堆他桌上（看不过来）
❌ 也不能只给他一张纸（不够用）
✅ 你得当一个好秘书：
- 当前任务相关的文件放最显眼位置
- 不重要的暂时收起来
- 之前做过的笔记，关键时刻递给他
- 工具说明书要简短精确

这就是 Context Engineering：精确管理 AI 视野里的每一个 token。

代表产品的共同特点

产品	主打场景	Context 工程的核心
Cursor	AI 写代码	知道该把项目里哪几个文件塞给模型看
Manus	通用 Agent	长任务中持续维护工作记忆与中间产物
GenSpark	AI 搜索/研究	把海量搜索结果压缩成模型能消化的精华

阶段特征

维度	状态
主导方	工程系统主导内容流转
交互模式	模型只是”流水线上的一个工位”
关键技术	RAG、向量检索、上下文压缩、多轮记忆
工程复杂度	高（要管整个信息生命周期）

📖 与本节深度相关：上下文窗口与Token计费 | RAG学习笔记

4. 阶段四：Harness Engineering（外壳/挽具工程）

代表产品：Claude Code、Codex、Hermes、OpenHands（课程 PPT 写成 OpenClaw） 核心命题：造一整套工程化外壳，让 AI 真正像一个开发者一样工作几小时不出错

生动比喻

助理现在要升级成 全能员工 了。光给他看文件不行，你得给他配齐一整套作战装备：

装备	对应工程能力
🛠️ 工具箱	让他能执行命令、读写文件、调 API（Tool Use）
📓 工作笔记本	长期记忆，记住”上次客户偏好深色主题”
✅ 任务清单 (TODO)	不会忘自己要干啥
🔍 代码审阅员	干完活有人帮他 review（subagent）
🪝 安全开关 (Hooks)	危险操作自动拦截（比如 `rm -rf /`）
🧰 可复用技能库 (Skills)	“上次怎么处理 PDF 的，存下来下次直接调用”
🪞 自我反思机制	错了能复盘改进
🌳 隔离环境 (Worktree/沙箱)	不会把你电脑搞坏

这一整套 “包在大模型外面、让它能真的把事做完” 的工程系统，就是 Harness Engineering。

Claude Code 是典型代表

你现在正在用的 Claude Code，就是 Harness Engineering 的典型代表。

它不是一个新模型，它是一套围绕 Claude 模型的 外壳工程：包含 hooks、skills、subagents、worktrees、todo、memory…… 几百个工程组件，工程代码量比模型本身还复杂。

阶段特征

维度	状态
主导方	整个外壳系统主导，模型是”内核 CPU”
交互模式	长任务、多 Agent 协作、自我进化
关键技术	Hooks、Skills、Subagents、Memory、Sandbox
工程复杂度	极高（几十万行工程代码）

📖 这一阶段的工程细节，本知识库另有专文：Harness工程与Agent解剖

5. 关键洞察：四阶段是”俄罗斯套娃”，不是并列

这是最反直觉、也最重要的一点：新阶段不是替代旧阶段，而是把旧阶段”包进来”。

层级关系图

┌────────────────────────────────────────────┐
│       Harness Engineering (最外层)          │
│  ┌──────────────────────────────────┐      │
│  │      Context Engineering         │      │
│  │   ┌──────Reasoning───────┐       │      │
│  │   │                      │       │      │
│  │   │  ┌─Prompt Engine─┐   │       │      │
│  │   │  │   (最内核)     │   │       │      │
│  │   │  └───────────────┘   │       │      │
│  │   │       ReAct          │       │      │
│  │   └──────────────────────┘       │      │
│  └──────────────────────────────────┘      │
└────────────────────────────────────────────┘

最贴切的比喻：开餐厅

阶段	对应角色
Prompt Engineering	一个会做菜的厨师（核心能力）
Reasoning / ReAct	厨师有了菜谱和”试吃-调整”的能力
Context Engineering	厨师配了一个备菜员，把该用的食材在该用的时候递到他手上
Harness Engineering	整个餐厅：前台、点餐系统、洗碗机、收银、安保、卫生检查、库存管理……

⚡ 关键结论：

没有最外层的”餐厅”，光有厨师再牛也开不了店

但餐厅里厨师还是核心，菜谱还是要写好

所以 学 Prompt Engineering 没过时，它只是变成了 Harness Engineering 的”内核”

6. Agent 演进的 4 个深层趋势

行业里常被引用的四句判断，背后对应四个深层趋势：

① “AI Coding 完成任务的比例越来越高”

越往右走，AI 自己写代码、自己执行的比例越大，人只是发号施令。

ChatGPT 时代：人写 99%，AI 给思路
Cursor 时代：人写 50%，AI 写 50%
Claude Code 时代：人写 10%，AI 写 90%

② “Agent 内部的工程代码复杂度越来越高”

ChatGPT 时代：包装代码可能就几百行
Claude Code 时代：工程代码量已经几十万行——比模型本身还复杂

③ “通过保存 Skill 复用代码和经验”

AI 第一次写过的”PDF 解析脚本”被存起来，下次类似任务直接拿来用，不用重新发明轮子。这就是 Claude Code 的 Skills 机制。

④ “记忆和自我进化机制初步形成”

AI 开始有：

长期记忆（记住你的偏好、项目历史）
自我学习（从失败中改进、积累 Skills）

这是 Agent 走向”真正员工”的关键一步。

7. 拓展：你还需要知道的几个关键词

7.1 Tool Use（工具使用）

让 AI 能调用外部工具（搜索、计算器、运行代码）。是 Harness 的基础能力。

没有 Tool Use 的 AI，只能”说”不能”做”。

7.2 MCP（Model Context Protocol）

Anthropic 提出的一个 标准协议，让任何工具都能”插”到 AI 上，类似 USB 接口。Claude Code 就大量用 MCP 接入第三方服务。

7.3 Agent 的”自主等级”（类比自动驾驶）

等级	能力	代表
L1	你问一句答一句	ChatGPT
L2	你给个目标，它走几步	AutoGPT
L3	能自己规划复杂任务	Manus、Cursor
L4	能干几小时活、自我纠错	Claude Code、Codex
L5	完全自主	还没到

7.4 为什么 Harness Engineering 是当前热点

大家发现：模型能力的天花板，已经被工程外壳的天花板限制住了。

同一个 Claude 模型：

套上 Claude Code 的 Harness：能干 8 小时编码任务
套个简陋外壳：可能 5 分钟就跑偏

Harness 决定了模型能力能释放多少。这也是开源模型追平闭源模型后，护城河从模型转向 Harness 的根本原因。

8. 给小白的入门路径建议

Step 1: 用好 ChatGPT/Claude 网页版
        ↓ （感受 Prompt Engineering）
Step 2: 试用 Cursor 写代码
        ↓ （感受 Context Engineering 的威力）
Step 3: 试用 Claude Code（你正在用）
        ↓ （亲身体会 Harness Engineering）
Step 4: 想深入？读 Anthropic 官方博客
        《Building effective agents》

一句话总结

AI 的进化史，就是从”教 AI 怎么答题”，进化到”造一个能让 AI 像员工一样上班的公司”的历史。

Prompt 是嘴，Reasoning 是脑，Context 是眼，Harness 是整副身躯——四者层层包裹，缺一不可。

9. 与本知识库其他章节的关联

关联点	文档	关系
Harness 工程深度解剖	Harness工程与Agent解剖	本文是”史观”，那篇是”工程解剖”，互补阅读
Token / Context 窗口	上下文窗口与Token计费	第三阶段 Context Engineering 的物理基础
RAG 检索增强	RAG学习笔记	Context Engineering 的核心实现技术
Transformer 基础	Transformer	所有阶段的最底层”引擎”
提示词工程子项目	02_提示词工程	第一阶段的系统化教程
Multi-Agent 实战案例	Multi-Agent 工程实战与 Persona 设计	第四阶段 Harness Engineering 中”多 Agent 协作”的具体落地例(7 人量化团队 + Persona 文件结构 + 四大工程原则)

10. 职业视角：什么是 Agent 架构师

前面九节讲的是 Agent 这门技术的演进。这一节换个角度——从人才市场的视角看：当 Harness Engineering 复杂到几十万行工程代码时，市场上需要一种新角色——「Agent 架构师」。

10.1 一个流行的定义（来自国内某课程 PPT）

Agent 架构师 = 设计、搭建、管控企业级智能体系统的高端架构师

不是写小玩具，是做企业级智能系统。

三大职责：

职责	含义
定架构	控制面 / 执行面 / 状态层
管协同	多 Agent 分工、调度、编排
保生产	安全、可靠性、可观测、可落地

知识融合：大模型原理 + 状态机 + 规划算法 + 流程编排 + 记忆系统 + 多智能体博弈 + 工程架构设计 + 系统容错与监控。

10.2 这个定义说对了什么

✅ “控制面 / 执行面 / 状态层” 借云原生术语很专业

直接套用了 Kubernetes 的 control plane / data plane / state 概念，准确指出：Agent 系统的工程结构和分布式系统是同构的。

对照本知识库已有的 Agent 五层解剖图：

「Agent 架构师」三分法	本库「五层架构图」
控制面	编排层
执行面	执行层
状态层	记忆层
（隐含）	大模型
❌ 没提	反馈层 ← 缺失项

✅ “保生产” 四要素是工业界的硬通货

安全 / 可靠性 / 可观测 / 可落地 这四个词不是口号，对应的是 SRE 实践里的真东西：

安全 = 权限闸门 + 沙箱
可靠性 = 错误恢复 + 重试 + 降级
可观测 = 日志 / Tracing / Metrics
可落地 = 部署 / 版本管理 / 回滚

✅ “不是写小玩具，是做企业级”——精准戳中真实鸿沟

Toy Agent（玩具）          Production Agent（生产）
────────────────           ────────────────────
跑通一个 demo  →           连续跑 8 小时不挂
准确率 70%    →           p99 准确率 99%
炫酷           →           可观测、可回滚、可审计

跨过这道坎的工程难度差 2 个数量级。

10.3 这个定义的可商榷之处

⚠️ “Agent 架构师” 当前是造词 / 营销词，不是稳定职业

业界更常见的标准 title：

真实存在的 title	国内培训圈造词
AI Engineer	”Agent 架构师”
Applied AI Engineer	”AI 系统总师”
LLM Systems Engineer	”智能体架构师”
ML Platform Engineer	”大模型架构师”

这种 title 大概率出自国内 AI 培训课的造词（典型特征：标题加引号、配色用荧光黄、口号化文案）。不是说这个角色不存在，而是这个 title 本身没立稳——招聘网站上几乎搜不到。

⚠️ 漏了最关键的一块：反馈与评测（Eval）

反馈层（Sensors）和评测体系（Eval）是 Production Agent 的命根子：

测试失败怎么回灌给模型？
模型答错怎么自动检测？
怎么离线 benchmark 不同 prompt / 模型 / 工具的效果？
上线后怎么持续监控质量退化？

没有反馈与 Eval 的 Agent 架构师，就像没有体检设备的医生——能开方子，但不知道病人现在好没好。

⚠️ “多智能体博弈”用得有点炫技

“博弈”（game theory）主要是研究界用语。真实工业 multi-agent 系统 90% 是分工协作（如 Claude Code 的 subagent 派生），不涉及”博弈”。

10.4 真实”Agent 架构师”还需要的硬技能

这套定义没列出、但工业界真正看重的：

缺失能力	为什么关键
Prompt 调优 / 上下文压缩	Token 是钱，每减 30% token = 直接省 30% 成本
Eval 体系搭建	离线评测 + 在线 A/B + LLM-as-judge 是质量保障的根本
成本 / 延迟工程	选 Opus 还是 Haiku？什么时候用缓存？决定毛利率
失败模式分析	Agent 100 种死法，每一种都要有兜底（依赖状态机设计；安全维度的失败模式见 Agent 安全攻防）
数据飞轮设计	把用户使用数据回灌成训练 / 评测样本，真正的护城河

10.5 “Agent 架构师”概念的综合评分

维度	分数	理由
概念覆盖面	8/10	大方向都点到了
术语准确性	7/10	借用云原生术语漂亮，但漏掉反馈层
实操指导性	5/10	偏口号，缺落地清单
行业立场	6/10	培训课造词痕迹明显
综合	6.5 / 10	看个轮廓不错，别当圣经

10.6 一句话结论

想成为”Agent 架构师”，别只看培训课的口号。

真功夫在三件事上：

看得懂 Harness——从 Claude Code 这种生产级系统反推架构

算得清账——Token、Latency、Eval 准确率，每一项都有数

救得了火——Agent 100 种死法你都见过、都有预案

10.7 术语速查：状态机与数据飞轮

§ 10.1 / 10.4 里出现了两个 Agent 工程的核心术语，单独展开。

10.7.1 状态机（State Machine）

一句话：一个东西在不同时刻处于不同的”状态”，状态之间按固定规则转换。Agent 本身就是一台精密的状态机。

生活类比（处处都是状态机）：

场景	状态	转换触发
红绿灯	红 / 黄 / 绿	定时切换
自动售货机	等待 → 投币 → 选货 → 出货 → 找零 → 等待	用户操作
电梯	停 / 上行 / 下行	按键
微信消息	未读 → 已读 → 已撤回	用户行为
游戏角色	站立 / 行走 / 跳跃 / 受伤 / 死亡	操作或事件

三件套：

状态（State）——有限的、明确的几种情况
事件（Event）——触发状态切换的输入
转换（Transition）——从 A 状态到 B 状态的规则

为什么 Agent = 状态机：

ReAct 循环本质上就是一台状态机：

[等待任务]
    ↓ 用户发请求
[思考规划] (Thought)
    ↓ 想好了
[调用工具] (Action)
    ↓ 工具返回
[观察结果] (Observation)
    ├─ 没完成 → 回到 [思考规划]
    └─ 完成了 → [回报用户] → [等待任务]

Claude Code 那 46000 行的 query engine，可以理解成一个超级精密的状态机。

一个真实的 Agent 状态机（带容错）：

IDLE（待命）
  ↓ 收到任务
PLANNING（规划）
  ↓ 拆出 todo
TOOL_CALL（调用工具）
  ↓ 等待
AWAIT_RESULT
  ↓ 工具返回
EVALUATE（评估）
  ├─ 失败 → 回 TOOL_CALL（重试，最多 3 次）
  ├─ 失败 3 次 → ASK_USER（问用户）
  └─ 成功 → 检查 todo
              ├─ 还有 → 回 PLANNING
              └─ 完成 → DONE → IDLE

状态机设计不好的典型 Bug：

设计问题	Agent 表现
状态没有”出口”	死循环，反复调同一个工具
漏了”失败”状态	工具一报错 Agent 崩溃
缺”等待用户确认”状态	Agent 擅自删文件（红灯区无人闸门）
缺”记忆压缩”状态转换	上下文溢出爆炸

10.7.2 数据飞轮（Data Flywheel）

一句话：产品越用越多 → 数据越多 → 系统越好 → 吸引更多人用 → 数据更多……一个自我增强的正反馈循环。

词源：物理飞轮（机械大圆盘）启动很费劲、推不动，但一旦转起来惯性巨大、停不下来。亚马逊 Bezos 把这个比喻引入商业，成了著名的 Amazon Flywheel。

经典案例：

公司	飞轮怎么转
Google 搜索	用户搜 → 点哪个结果 → 知道哪个好 → 排序更准 → 更多人用
抖音 / TikTok	看视频 → 知道你喜欢啥 → 推荐更准 → 看更久 → 更多数据
Tesla 自动驾驶	车在路上跑 → 收驾驶数据 → 训模型 → 自动驾驶更强 → 卖更多
ChatGPT	用户对话 → 给 👍/👎 → 训 reward model → 模型更聪明 → 更多人用

Agent 时代的数据飞轮：

              ┌──────────────────┐
              │  用户使用 Agent   │
              └────────┬─────────┘
                       ↓ 产生数据
  ┌────────────────────┴────────────────────┐
  │ • 用户接受/拒绝 AI 建议（偏好数据）        │
  │ • 用户改了 AI 写的代码（"正确答案"对照）    │
  │ • 测试失败 / AI 自动修对了吗（错误模式）    │
  │ • 一个任务来回沟通几轮（首次完成率低样本）   │
  └────────────────────┬────────────────────┘
                       ↓ 数据被收集 / 清洗 / 利用
  ┌────────────────────┴────────────────────┐
  │ ① 改 system prompt（把常见错误写成规则）   │
  │ ② 构建 Eval 数据集（持续测试质量）         │
  │ ③ 微调模型 / 训 reward model              │
  │ ④ 发现新失败模式 → 加 hooks / sub-agent    │
  └────────────────────┬────────────────────┘
                       ↓
              ┌────────┴─────────┐
              │  Agent 更强、更准 │
              └────────┬─────────┘
                       ↓
              ┌────────┴─────────┐
              │ 更多人用、用得更深 │ ──→ 回到顶部
              └──────────────────┘

Cursor / Claude Code 飞轮的真实燃料：

你的动作	平台获得的免费数据
接受 AI 建议（点 ✓）	“这个建议是对的”
拒绝 AI 建议（点 ✗）	“这个建议是错的”
自己改了 AI 写的代码	”AI 写的 vs 正确答案” 对照样本
跑测试失败了	一种新的错误模式被记录
一个任务来回沟通 5 轮	”首次完成率低” 的失败案例

有飞轮 vs 没飞轮的差距：

时间点	没飞轮	有飞轮
第 1 天	准确率 70%	准确率 70%
第 30 天	70%	78%
第 180 天	70%	90%
护城河	❌ 谁都能复制	✅ 数据偷不走

🔥 同一个基础模型，飞轮转得快的产品 6 个月后能甩开对手 10 倍。这是 Agent 创业最重要的护城河——模型可以买，飞轮买不到。

飞轮设计的 4 大难点：

难点	具体问题
怎么收	不能侵犯隐私，不能弹窗骚扰用户
怎么标	人工标贵、自动标容易污染
怎么回灌	喂模型？做 RAG？还是改 prompt？
怎么验证	这次更新真变好了吗？还是只过拟合到老用户？

10.7.3 两者的关系

   数据飞轮（外层 - 全局 / 长期）
   ┌──────────────────────────────┐
   │  收集真实使用数据 → 改进系统    │
   │                                │
   │   ┌──────────────────────┐     │
   │   │  状态机（内层 - 微观） │     │
   │   │  Agent 单次任务的执行  │     │
   │   │  流程引擎              │     │
   │   └──────────────────────┘     │
   │                                │
   └──────────────────────────────┘

状态机管的是 单次任务怎么走完（微观、内部）
数据飞轮管的是 整个产品怎么越用越聪明（宏观、外部）

一个是钟表的齿轮，一个是钟表越走越准的进化机制。

附：原始素材

本文整理自 2026-04-21 与 AI 关于”Agent 发展轨迹”两张课程截图的交流：

图 1：Agent 的发展轨迹四阶段图（Prompt → Reasoning/ReAct → Context → Harness）
图 2：四阶段的”俄罗斯套娃”包含关系图（Harness 是最外层的工程外壳）
图 3（§ 10 来源）：「什么叫 Agent 架构师？」职业定义图——三大职责（定架构 / 管协同 / 保生产）+ 八项知识融合

核心金句：“包裹着大模型的这套工程外壳，就是 Harness Engineering”。

与 AI 交流 AI

探索

Agent发展轨迹四阶段

Agent 的发展轨迹：从”会聊天”到”会干活”的四阶段演进

目录

0. 给小白的总体画面感

1. 阶段一：Prompt Engineering（提示词工程）

生动比喻

阶段特征

这个阶段没过时

2. 阶段二：Reasoning + ReAct（推理 + 行动）

生动比喻

ReAct 的经典套路

阶段特征

代表产品的不同侧重

3. 阶段三：Context Engineering（上下文工程）

为什么会出现这个阶段

生动比喻

代表产品的共同特点

阶段特征

4. 阶段四：Harness Engineering（外壳/挽具工程）

生动比喻

Claude Code 是典型代表

阶段特征

5. 关键洞察：四阶段是”俄罗斯套娃”，不是并列

层级关系图

最贴切的比喻：开餐厅

6. Agent 演进的 4 个深层趋势

① “AI Coding 完成任务的比例越来越高”

② “Agent 内部的工程代码复杂度越来越高”

③ “通过保存 Skill 复用代码和经验”

④ “记忆和自我进化机制初步形成”

7. 拓展：你还需要知道的几个关键词

7.1 Tool Use（工具使用）

7.2 MCP（Model Context Protocol）

7.3 Agent 的”自主等级”（类比自动驾驶）

7.4 为什么 Harness Engineering 是当前热点

8. 给小白的入门路径建议

一句话总结

9. 与本知识库其他章节的关联

10. 职业视角：什么是 Agent 架构师

10.1 一个流行的定义（来自国内某课程 PPT）

10.2 这个定义说对了什么

✅ “控制面 / 执行面 / 状态层” 借云原生术语很专业

✅ “保生产” 四要素是工业界的硬通货

✅ “不是写小玩具，是做企业级”——精准戳中真实鸿沟

10.3 这个定义的可商榷之处

⚠️ “Agent 架构师” 当前是造词 / 营销词，不是稳定职业

⚠️ 漏了最关键的一块：反馈与评测（Eval）

⚠️ “多智能体博弈”用得有点炫技

10.4 真实”Agent 架构师”还需要的硬技能

10.5 “Agent 架构师”概念的综合评分

10.6 一句话结论

10.7 术语速查：状态机 与 数据飞轮

10.7.1 状态机（State Machine）

10.7.2 数据飞轮（Data Flywheel）

10.7.3 两者的关系

附：原始素材

关系图谱

目录

反向链接

10.7 术语速查：状态机与数据飞轮