Agent on Renxin's Blog

你其实不需要更强的模型

Fri, 17 Jul 2026 00:00:00 +0000

你有没有这样一种感觉——

2023 年用上 GPT-4 的时候，那种震撼是真实的：它居然能写代码、能推理、能理解上下文。每发布一个新版本，你会迫不及待去试。但现在呢？GPT-5.6 发布了、Claude Fable 5 来了、Kimi K3 也出来了——你的第一反应是不是变成了：「哦，又强了一点。」

不是它们不够强。GPT-5.6 Sol 在复杂推理上确实甩开了上一代一大截。问题在于：你 90% 的日常任务，两三年前的模型就已经够用了。

这不是观点，是正在发生的现实。这篇不聊模型有多强，聊一个更实际的问题——为什么大部分 AI 项目依然在失败，以及真正该花精力在什么地方。

2026 年的模型版图

先看看我们现在有什么。

把今天的主流模型放在一张图里，按能力和价格两个维度看：

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 经济层["💰 经济层
$0.10-0.50/1M 输入"] -->|"80% 日常任务"| 日常["分类/提取/摘要
客服/简单推理"]
 主力层["🔋 主力层
$2-3/1M 输入"] -->|"15% 复杂任务"| 复杂["多步推理
长文档分析"]
 旗舰层["🚀 旗舰层
$5-10/1M 输入"] -->|"5% 特殊场景"| 特殊["高难度代码
研究级分析"]
 style 经济层 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 主力层 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 旗舰层 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 日常 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 复杂 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 特殊 fill:#fef3c7,stroke:#d97706,color:#78350f

数据来源：OpenRouter API（2026-07 实时定价），涵盖 344 个模型。OpenAI GPT-5.6 于 2026 年 7 月 9 日发布，Claude Fable 5 于 6 月 9 日发布。DeepSeek V4 Pro 于 4 月开源，1.6T 参数/49B 活跃参数，1M 上下文。Kimi K3 据称可媲美 OpenAI 和 Anthropic 的旗舰模型。

这张图的信息量比看起来大。注意定价跨度——旗舰层和主力层之间是 5-10 倍的价格差，和 DeepSeek V4 Flash 比更是 100 倍的差距。更深层的信号是：经济层的模型能力线已经远远到了日常任务「够用」的基准线之上。 日常任务不需要旗舰模型的原因不是「没钱」，是「没必要」。

80/15/5 的分层现实

那实际在用的时候是怎么选的？

以我托管的 hermes-home 多 Agent 系统为例——它跑着 7 个 Agent，每天处理调研、写作、决策分析、知识管理等任务。实际用量比例：

层级	模型	用量	场景
经济层	DeepSeek V4 Pro（$0.44）	~80%	日常推理、内容生成、知识检索、决策辅助
主力层	GPT-5.6 Luna（$1.00）	~15%	需要更强推理能力的复杂任务
旗舰层	GPT-5.6 Sol / Claude Fable 5	~5%	高难度代码生成、架构设计、研究级分析

这不是预算问题。换成 DeepSeek V4 Pro 每百万 token 只需 $0.44，全跑旗舰模型（Claude Fable 5 $10/1M）也就多花二十几倍。真正的原因是：对于 80% 的任务，换旗舰模型的提升用户感知不到。

写一篇博客、整理一份调研、做一个决策分析——这些任务 DeepSeek V4 Pro 完成得很好。只有当你需要处理极其复杂的推理链条、或者生成需要深度理解上下文的高难度代码时，旗舰模型的优势才会显现。而且即便是这些时候，差距也在快速缩小：DeepSeek V4 Pro 的 Benchmark 已经追平了两年前的旗舰模型。

现在，旗舰模型针对的是「不可能轻松做到的业务」，是「需要博士级的研究分析」，是「5% 的场景」。大部分公司的绝大部分业务和大部分个人的日常任务，处在那个 80% 的范围内。

AI 项目真正的死因

如果模型已经够用了，那为什么那么多 AI 项目还是失败了？

RAND 公司对 65 个企业 AI 项目的元分析给出了一个发人深省的数字：80% 的企业 AI 项目以失败告终。 Gartner 的追踪数据给出了类似的结论，MIT 的研究甚至将这个比例推高到了 95%。这些项目不是用 DeepSeek V4 Pro 做的——很多花了大价钱上了最好的模型。

导致项目失败的原因，排在最前面的从来不是「模型不够聪明」。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 模型["📈 模型能力
飞速提升"] -->|"但……"| 失败["⚠️ 80-95% 项目失败"]
 失败 --> 根因["为什么失败？"]
 根因 --> 需求["❌ 需求没挖对
解决了错误的问题"]
 根因 --> 成本["❌ 成本跑飞了
不分层 > 预算超支"]
 根因 --> 工程["❌ 工程不靠谱
缺乏可观测性和错误处理"]
 style 模型 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 失败 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 根因 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 需求 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 成本 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 工程 fill:#fecaca,stroke:#dc2626,color:#7f1d1d

数据来源：RAND 企业 AI 元分析（65 个项目，80% 失败率）、MIT 研究（95% 企业 AI 项目未交付价值）。

我跑了几个月多 Agent 系统，最深的感受就是：模型从来不是瓶颈。 出错最多的地方，永远是需求没对齐、成本估算偏差、以及系统工程的细节。

真正卡脖子的三件事

如果瓶颈不是模型，那是什么？基于实战观察，我认为有三件事比模型选型重要得多。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 旧认知["过去以为瓶颈
是模型能力"] --> 新认知["实际瓶颈
（三件事）"]
 新认知 --> 需求挖掘["🔍 需求挖掘
解决对的问题"]
 新认知 --> 成本控制["💰 成本控制
分层选型不跑偏"]
 新认知 --> Agent工程["⚙️ Agent 工程
可靠系统需要 Engineering"]
 style 旧认知 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 新认知 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 需求挖掘 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 成本控制 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style Agent工程 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f

需求挖掘：你确定你在解决对的问题？

大部分 AI 项目死得冤枉。团队花了几周时间搭建一个完美的 RAG 流水线，上线后发现用户根本不需要这个功能。或者花了大价钱微调了一个模型，结果业务需求已经变了。

这不是技术问题，这是需求挖掘问题。一个简单的判断标准：你能否一句话说清楚「这个 AI 系统做成了，用户的什么行为会改变？」 如果你说不清楚，模型再强也没用。

真实教训：hermes-home 里有一个 Agent 最早的设计是「帮我决定今天做什么」，上线后完全没人用。后来改成「帮我记录和管理待办事项」，用户每天在用。模型没换，Prompt 也没大幅改——换的是解决哪个问题。

成本控制：不分层的架构跑不远

很多团队的做法是：选一个最强的模型，全量流量都走它。结果第一个月账单出来，团队傻眼了。

分层的逻辑很简单：不是所有请求都值得用最好的模型处理。 80% 的请求可以用 DeepSeek V4 Pro 甚至 V4 Flash，15% 需要 GPT-5.6 Luna 级别，只有 5% 需要动用旗舰模型。

实操层面，成本优化的手段远不止分层：

语义缓存：重复查询命中缓存，彻底省掉模型调用
Prompt 压缩：精简历史记录和上下文，减少 token 消耗
Fallback 链：小模型先处理，处理不了再升级到大模型
输出长度控制：很多场景不需要完整输出，设置 max_tokens 能省一大半

2026 年的行业共识是：一个设计良好的分层架构，可以将 LLM 成本降低 30-50%，同时保持 95% 以上的用户体验不下降。

Agent 工程：能力是 Engineering 出来的，不是模型送过来的

这是最容易被忽视、但也是真正的壁垒所在。

从 GPT-3.5 到 GPT-5.6，模型能力在涨。但把一个 LLM 从「能回答问题」变成「能可靠地完成一个任务」，需要的是一整套工程能力——

Tool 设计：模型需要知道自己有什么工具可用，每个工具的输入输出是什么，什么时候该用哪个
Memory 管理：会话历史、长期记忆、知识库检索——怎么存、怎么查、怎么不爆上下文
错误处理：模型调用超时怎么办？工具返回异常怎么办？重试逻辑怎么写？
可观测性：每次调用花了多少 token？哪个环节耗时最长？出错了怎么定位？
多 Agent 协作：多个 Agent 之间怎么发现彼此的能力、怎么传递任务、怎么避免冲突

这些东西，换再强的模型也不会自动变好。它们需要工程投入。

实战案例：一个跑在 DeepSeek 上的多 Agent 系统

hermes-home 是一个真实运行的多 Agent 系统，7 个 Agent 分布在云服务器和本地 Docker 中，通过 MCP 协议通信。这个系统 80% 的请求由 DeepSeek V4 Pro 处理。

它能做什么？

知识库 Agent 每天自动扫描 GitHub 新项目，整理入库
博客 Agent 从知识库拉取素材，写成 Hugo 文章并部署
待办 Agent 管理日常任务并定时提醒
决策 Agent 综合分析多个来源，给出结构化建议

所有这些任务，没有一个需要用到 Claude Fable 5 的全能力量。系统的瓶颈从来不在模型能力上——而是在 Tool 设计得够不够好、Memory 管理得够不够稳定、错误处理得够不够健壮。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 subgraph 模型层["模型层 (80% DeepSeek V4 Pro)"]
 A["LLM 推理"]
 end
 subgraph 工程层["工程层 (真正的壁垒)"]
 B["Tool 系统"]
 C["Memory 管理"]
 D["错误处理"]
 E["可观测性"]
 end
 subgraph 应用层["应用层"]
 F["7 个 Agent
调研/写作/决策/待办"]
 end
 A --> B --> C --> D --> E --> F
 style 模型层 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 工程层 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 应用层 fill:#fef3c7,stroke:#d97706,color:#78350f

我花了大量时间优化的是中间这一层——Tool 的接口设计、Memory 的持久化策略、错误恢复逻辑、以及每次调用链路的可观测性。这些才是真正决定系统质量的因素。模型只要「够用」就行。

下次有新模型发布的时候，先问自己三个问题：

我的瓶颈真的是模型能力吗？ ——还是需求没挖对、成本没控好、工程没做扎实？
换模型能解决我的什么问题？ ——它会让用户感知到显著提升吗？
我的系统有足够好的可观测性吗？ ——如果你不知道每次调用花在哪、错在哪，换模型就是盲人摸象。

模型在飞速进步，这是好事。但 90% 的日常任务已经越过了「够用」的基准线。 真正的差距，从来不在模型本身。

数据来源：OpenRouter API 实时定价、DeepSeek 官方发布公告（2026-04-24）、OpenAI GPT-5.6 官方公告（2026-07-09）、Anthropic Claude Fable 5 公告（2026-06-09）、RAND 企业 AI 项目元分析、AP News Kimi K3 报道。

从聊天到干活：LLM 是怎么一步步变成 Agent 的

Wed, 08 Jul 2026 00:00:00 +0000

你有没有想过一个问题——

几年前我们用 LLM，还只是拿来聊天查资料，把它当做一个更高效的搜索引擎。你问它一句，它答一句，答完就结束了。怎么现在它们突然就能干活了？调接口、读文件、写代码、自己决定下一步做什么——这些东西跟文本生成有什么关系？

答案是：从「聊天」到「干活」，中间叠加了好几层工程手段。每一层解决一个问题，又会暴露一个更深层的问题。我们这篇文章就沿着这条问题链往下分析。

第一层：LLM 本身什么也干不了

我们都知道 LLM 的本质是一个一次性的文本预测器：你给它输入一段文本，它就输出一段文本，然后结束。总体而言，它有四个根本限制：

限制	什么意思
无状态	每次调用是独立的。不记得上一次聊了什么，除非把历史都塞回去
无行动能力	只能输出文字。不能调 API、不能读文件、不能执行命令
知识截止	训练完之后就停在那个时间点了，不知道最新消息
单步推理	复杂任务需要多步，它只能走一步

这些限制在简单问答场景下不明显——你问一句它答一句。但一旦任务变成「帮我排查一下这个 bug」，它需要：读文件 → 看报错 → 查文档 → 改代码 → 跑测试 → 看结果。这根本不是一次 LLM 调用能完成的。

那么：怎么让 LLM 做一个完整的事？

答案是：不给它加任何东西，它确实什么也干不了。但你可以围绕它叠加工程层——就像给一个只有大脑的躯体装上感官、手脚和神经系统。

%%{init: {'theme':'neutral'}}%%
graph TD
 subgraph Agent[Agent]
 direction TB
 subgraph 工程层[工程层]
 FC[Function Calling
让模型能输出工具调用] --> RA[ReAct 循环
持续行动 + 反馈]
 RA --> CM[上下文管理
不让循环撑爆窗口]
 CM --> MEM[记忆系统
跨会话复用经验]
 MEM --> HAR[Harness
统一框架装好一切]
 end

 subgraph 核心[核心 · LLM]
 LLM[LLM
文本预测器]
 end

 核心 -->|叠加| 工程层
 end

 style Agent fill:#f8fafc,stroke:#64748b,color:#0f172a
 style 核心 fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style 工程层 fill:#d1fae5,stroke:#059669,color:#064e3b
 style LLM fill:#eff6ff,stroke:#60a5fa,color:#1e3a5f
 style FC fill:#ecfdf5,stroke:#34d399,color:#064e3b
 style RA fill:#ecfdf5,stroke:#34d399,color:#064e3b
 style CM fill:#ecfdf5,stroke:#34d399,color:#064e3b
 style MEM fill:#ecfdf5,stroke:#34d399,color:#064e3b
 style HAR fill:#ecfdf5,stroke:#34d399,color:#064e3b

蓝色是 LLM 核心，绿色是工程层，整个大框就是 Agent。后面的章节就按这个顺序一层一层拆开来看。

第二层：Function Calling——让 LLM「说」出要调什么工具

在 Function Calling 出现之前，想让 LLM 调用工具，做法很原始。

你要在 prompt 里告诉 LLM：「你有哪些工具可以用、每个工具是干什么的、参数是什么」。然后 LLM 在回答的时候，把工具调用写在文本里——比如输出一段 JSON，或者一段特定格式的文字。你在代码里写一堆正则表达式去匹配这段文字，解析出工具名和参数，再去执行。

这个方法的问题很明显：LLM 输出文本是不受约束的。今天它输出 {"tool": "get_weather", "args": {"city": "北京"}}，明天它可能输出 让我来查一下北京的天气吧！[调用：get_weather(北京)]。格式稍微一变，你的正则就匹配不上了。而且每换一个模型，输出的格式习惯不一样，你的正则又得重写。

2023 年中，OpenAI 推出了 Function Calling。这个改动看似不大，但影响深远。

OpenAI 做的事其实就两件：第一，在模型微调阶段加入了大量「用户提问 → 模型输出 tool_calls」的训练样本，让模型学会在合适的时机输出结构化工具调用；第二，在 API 层面加了一个 tools 参数，开发者直接把工具定义传进去，模型输出里就会自动带上 tool_calls 字段。

至于微调数据具体怎么构造、工具调用的能力边界在哪里——这是个可以单独写一篇文章的话题，这里先不展开。

Function Calling 做的事很简单：模型在输出时，除了生成文本，还能输出一个结构化的对象，里面明确指定了要调什么工具、传什么参数。

// 以前的写法：模型用文字描述
输出："让我查一下天气。\n\n```json\n{\"tool\": \"get_weather\", \"args\": {\"city\": \"北京\"}}\n```"

// Function Calling：模型直接输出结构化调用
输出：{
 tool_calls: [{
 name: "get_weather",
 args: { city: "北京" }
 }]
}

区别在哪？第一个是「模型用文字描述了自己想做什么」，第二个是模型结构化地输出函数名称和参数列表——API 层收到后直接按这个字段去路由和执行，不需要任何文本解析。

说到这里你可能会好奇：LLM 不是拿对话和文本训练出来的吗，它怎么会「知道」要输出结构化的 tool_calls？

答案在微调阶段。OpenAI 在推出 Function Calling 之前，在微调数据里加入了大量「用户提问 → 模型输出 tool_calls」的训练样本。模型在预训练时就已经见过代码和 JSON，微调只是教它在什么时机输出：

%%{init: {'theme':'neutral'}}%%
graph LR
 subgraph 训练流程[LLM 训练流程]
 direction LR
 A[预训练
海量文本] --> B[监督微调 SFT
指令数据]
 B --> C[偏好对齐 RLHF
人类偏好]
 C --> D[工具调用微调
tool_calls 样本]
 end

 style 训练流程 fill:#f8fafc,stroke:#64748b,color:#0f172a
 style A fill:#eff6ff,stroke:#60a5fa,color:#1e3a5f
 style B fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style C fill:#d1fae5,stroke:#10b981,color:#064e3b
 style D fill:#ecfdf5,stroke:#34d399,color:#064e3b

最后一个阶段是关键。更直白一点：模型不是「学会调工具」，而是学会了「在需要调工具的场景下，输出一段看起来像 tool_calls 的 token 序列」。 它以为自己只是在接着写文本，但对使用者来说，它在干活。

清楚了 Function Calling 的原理之后，一个新的问题自然浮现了：光能说一次还不够——一个完整的任务往往需要多步操作：查了数据、分析、再查、再分析。能不能让模型不止调一次，而是一直干下去直到任务完成？

这就引出了下一层：ReAct 循环。

第三层：ReAct 循环——从一次调用到持续行动

一次 Function Calling 只能完成一步。要完成一个复杂任务，需要多步。这时候就需要一个循环。

ReAct（Reasoning + Acting）是 2022 年一篇论文提出的思路，核心骨架就是一个持续循环：

%%{init: {'theme':'neutral'}}%%
graph LR
 A[观察当前状态
Observation] --> B[推理下一步
Thought]
 B --> C{任务完成？}
 C -->|否| D[执行工具调用
Action]
 D --> A
 C -->|是| E[输出最终答案]

 style A fill:#eff6ff,stroke:#60a5fa,color:#1e3a5f
 style B fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style C fill:#fef9c3,stroke:#fbbf24,color:#92400e
 style D fill:#d1fae5,stroke:#10b981,color:#064e3b
 style E fill:#ecfdf5,stroke:#34d399,color:#064e3b

每一轮循环做三件事：

Thought：LLM 推理当前步骤。比如「发现了这个 bug，需要先看一下这个文件的源代码」
Action：LLM 输出一个工具调用。比如 read_file("src/main.py")
Observation：工具执行结果塞回下一轮 prompt，LLM 看到了继续推理

用代码实现也就几十行：

while not done:
 prompt = build_prompt(messages, observation)
 response = llm.chat(prompt)
 action = parse_action(response)
 if action.type == "final_answer":
 done = True
 else:
 observation = execute_tool(action.name, action.args)
 messages.append(response)
 messages.append(observation)

这个循环就是所有现代 Agent 的基座。Claude Code、Codex、Manus、Cline——不管上面叠了多少层，最底层跑的都是这个循环。

ReAct 循环很好用，任务越复杂跑的轮数就越多。但跑起来之后，人们很快发现一个问题：每轮都要把全部历史塞回 prompt，跑了 8 轮之后光历史记录可能就已经占了 30K token。而且很多早期的对话其实已经没用了——第一轮的推理早就被后续结果覆盖了。

Token 越积越多，效率越来越低——能不能在保留必要上下文的同时，不让循环撑爆窗口？

解决方法有几个方向：

策略	做法	适用场景
滑动窗口	只保留最近 N 轮对话，丢弃最旧的	简单任务，早期对话不重要
摘要压缩	把旧对话用 LLM 压缩成一段摘要	需要长期记忆的任务
结构化上下文	把历史信息按类型组织，LLM 按需读取	复杂任务
渐进性披露	不一次给全部信息，先给概要再展开	长文档分析

Mitchell Hashimoto（Harness Engineering 提出者）说过一句话：长上下文不是银弹。关键是上下文的质量和组织方式，不是长度。

对话管理解决了「一次任务内」的持久化问题。但关掉会话之后呢？下次遇到同样的问题，能不能复用上次的排查经验？

这就引出了下一层：记忆系统。

第五层：记忆——让经验跨会话复用

想象一个场景：上周花了半天排查了一个连接池超时问题，找到了根因。这周又遇到一个类似的报错，但你又得从头排查一遍——因为上次的排查结果在上次对话里，已经关了，没了。

这就是记忆要解决的问题。

记忆可以分为几个层次：

层次	存储方式	生命周期	示例
上下文窗口	prompt 里的消息列表	当前会话	刚才的对话历史
文件存储	Markdown / JSON 文件	持久化	MEMORY.md、USER.md
向量数据库	Embedding 检索	持久化	RAG 知识库
结构化数据库	PostgreSQL 等	持久化	业务实体、修复记录

关键点：分层不是替代关系，是互补关系。 文件层存结构化知识，向量层存语义可检索的内容，上下文层存当前会话的状态。实际工程中，通常会为每个 Agent 分配独立的数据库 schema，同时把技能和记忆以文件形式备份到代码仓库——既能在会话中快速检索，又能在仓库里版本回溯。

有了循环、上下文管理、记忆，LLM 终于能完整地完成一个任务了。但这些东西是一块一块拼上去的——Function Calling、ReAct、上下文管理、记忆，各是一套独立的组件。到了这一步，人们开始想：能不能把这些零散的组件装进一个统一的框架里？

第六层：Harness——给 LLM 装一个操作系统

Harness Engineering 的核心思想是：围绕 LLM 构建一个「操作系统」——包括工具系统、上下文管理、权限控制、反馈回路、可观测性。

没有 Harness 的话，做 Agent 就是 LLM + 循环 + 几个工具，拼起来就完事了。Harness 的视角不一样——它认为 Agent 能不能用好，瓶颈往往不在模型本身，而在于怎么装。

LangChain 的 Deep Agents 项目有一个实验很能说明问题：仅仅优化 Harness（不改模型），Terminal Bench 2.0 排名从第 30 位直接跃升至第 5 位。

Harness 有四条铁律：

工具签名即文档——每个工具的名称、参数、返回值本身就是使用说明
结果必须可验证——每一步的输出需要有明确的验证标准
错误不可沉默——所有失败必须可见并结构化回传（Error-as-Data）
渐进性披露——不要让 Agent 同时面对所有信息，按需呈现

除此之外，权限控制、反馈回路、可观测性也都是 Harness 的重要组成部分——这些是值得单独展开的话题，这里先不深入。

总结一下就是：Agent = LLM + Harness。LLM 负责推理，Harness 负责把它装好，让它能干活。

回头看整条演化路径

把这几层串起来，就是一条清晰的演化路径：

LLM → Agent 演化路径：六层叠加，每层解决上一层的新问题（点击图片查看大图）

每一层都在解决上一层暴露出来的新问题。LLM 本身没有变「更聪明」，但加上这些工程组件之后，它从一个只会聊天的文本预测器，变成了一个能干活、能调接口、能写代码、能自己决定下一步的 Agent。

从 Function Calling 到 ReAct 到 Harness，每一层都不复杂。就像搭积木——每一块都很简单，但搭对了顺序，就能搭出一个能干活的东西来。

AI Agent 入门：程序员视角的概念与实践

Sun, 05 Jul 2026 00:00:00 +0000

如果说 2024 年是"AI 聊天机器人"普及的一年，那么 2025-2026 年则是"AI Agent"从概念走向工程的一年。Claude Code、OpenAI Codex、Manus、Cline……越来越多的产品不再满足于"你问我答"，而是主动帮你完成任务——读代码、改文件、跑测试、甚至自己写一篇博客。

但 Agent 到底是什么？它和普通的 LLM 对话有什么区别？这篇文章将从程序员熟悉的概念出发，系统地梳理 AI Agent 的核心概念、关键特性和基础架构模式。

一、从对话到自主：Agent 的核心定义

最简单的定义来自 LangChain：

Agent = Model + Harness

翻译成程序员能理解的语言：Agent 不是更聪明的 LLM，而是把 LLM 装进了一个有工具、有记忆、有控制循环的"运行时环境"里。

你可以把 LLM 想象成一个天才程序员，但你只能跟他口头交流——他再聪明，不动手也写不了代码。Agent 就是给了这个天才一台电脑、一套工具链、和一份"你自己想办法搞定"的指令。

Anthropic 的 Barry Zhang 有一个更简洁的说法：

Agent = 在 Loop 中使用工具的模型

关键的区别在于：

特性	普通 LLM 对话	Agent
交互方式	一问一答	给定目标，自主行动
工具使用	不能	可以调 API、读写文件、执行命令
记忆	上下文窗口（易失）	持久化记忆（跨会话）
决策	用户决定下一步	自主决定下一步
错误处理	用户发现并纠正	自行检测和重试

二、Agent 的五个关键特性

从工程角度看，一个完整的 Agent 系统通常具备以下五个特性：

1. 工具调用（Tool-use）

Agent 不只"说"，还能"做"。通过工具调用操作外部系统——读文件、搜网页、发 API、执行命令。

💡 类比：工具的接口就像微服务的 API endpoint，有 schema、参数、返回值。Agent 根据任务自主选择调哪个"端点"。

2. 记忆（Memory）

Agent 需要跨会话记住你的偏好、工作环境、学到的经验。记忆分为多个层级：

文件层：MEMORY.md、USER.md 等结构化文件，持久化存储
语义层：向量检索，用于快速召回相关历史
上下文层：当前会话窗口，易失但高效

💡 类比：上下文窗口是 Redis（缓存，易失），文件系统是 PostgreSQL（持久存储）。

3. 规划（Planning）

复杂任务需要拆解。Agent 先制定计划（如 plan.md），再分步执行——每一步完成后再决定下一步做什么。

💡 类比：就像你写代码之前先画架构图、列 TODO 清单。Agent 也需要先规划再行动。

4. 自主决策（Autonomous Decision）

这是 Agent 和"带工具的聊天机器人"的本质区别。Agent 自主决定调哪个工具、用什么参数、是否重试。

关键设计原则：Error-as-Data。工具失败时，错误信息作为数据回写给 LLM，而不是抛异常——Agent 自己决定是重试还是换工具。

5. 验证与反馈（Verification）

Agent 需要自己检查结果是否正确。没有验证的 Agent 就像没有测试用例的 CI/CD 流水线——跑得再快也不知道对不对。

Boris Cherny（Claude Code 负责人）的一条核心经验：给 LLM 自我验证的能力，输出质量能提升 2-3 倍。

三、四层工程模型：理解 Agent 系统的骨架

这是理解 Agent 技术栈最清晰的可视化框架，由浅入深分为四层：

L4 Loop Engineering —— 设计替你跑 Agent 的系统
L3 Harness Engineering —— 怎么把 Agent 装好
L2 Context Engineering —— 怎么给 Agent 喂对信息
L1 Prompt Engineering —— 怎么把话说清楚

⚠️ 注意：四层是嵌套关系而非替代关系。L3 不覆盖 L2，而是在它上面叠加。

L1: Prompt Engineering

最基本的层次。研究"怎么写指令"能让 LLM 给出更好的回答。包括角色设定、示例引导、思维链（Chain-of-Thought）等技巧。

程序员熟悉的起点：就像写一个好的函数注释和调用说明。不同之处在于 Prompt 的"读者"是 LLM，它比编译器宽容得多，但也会产生你意想不到的输出。

L2: Context Engineering

这一层关注"给 LLM 什么信息"。Andrej Karpathy 提出的概念——长上下文不是银弹，关键是上下文的质量和结构。

核心实践包括：

渐进性披露：先给概要，逐步展开细节，避免信息过载
上下文窗口管理：当上下文超长时，如何压缩、优先排序、丢弃
结构化上下文：用 XML、JSON 等格式组织信息，让 LLM 更容易解析

💡 类比：Prompt Engineering 是"怎么问"，Context Engineering 是"给什么参考材料"。

L3: Harness Engineering

这是 Agent 工程的核心创新层。Mitchell Hashimoto（Harness Engineering 提出者）将其定义为：

围绕 LLM 构建一个"操作系统"——包括工具系统、权限控制、上下文管理、反馈回路、可观测性。

Harness 的四条铁律：

工具签名即文档 — 每个工具的名称、参数、返回值的设计本身就是使用说明
结果必须可验证 — 每一步的输出需要有明确的验证标准
错误不可沉默 — 所有失败必须可见并结构化回传（Error-as-Data）
渐进性披露 — 不要让 Agent 同时面对所有信息，按需呈现

LangChain 的 Deep Agents 项目做过一个令人印象深刻的实验：仅仅优化 Harness（不改模型），Terminal Bench 2.0 排名从第 30 位直接跃升至第 5 位。 这证明了瓶颈往往不在模型本身，而在"怎么装"。

L4: Loop Engineering

最高层次，研究"自动触发 Agent 的循环系统"。不是你自己跑一次 Agent，而是系统定期或按事件自动启动 Agent。

Boris Cherny 的实践是代表性案例——他不再"提示"Claude，而是"写循环"（I don’t prompt Claude anymore. I write loops.）。

典型的 Loop 模式：

事件驱动：文件变更 → 自动触发代码审查
定时任务：每日自动抓取信息、生成摘要
Pipeline：多个 Agent 接力完成复杂工作流

四、基础架构模式

4.1 ReAct Loop（核心循环）

ReAct（Reasoning + Acting）是所有现代 Agent 的基座模式。它的执行循环可以用一行伪代码概括：

while (task_not_complete) {
 think() // 推理：当前状态 + 下一步做什么
 act() // 行动：调用工具或生成输出
 observe() // 观察：收集执行结果
}

Manus、Cline、Claude Code 都是 ReAct Loop 的具体实现。不管上层叠了多少层 Harness 或 Loop，最底层永远是 observe-think-act 这个基本循环。

💡 类比：一个 while(true) { think → act → observe } 的事件循环。Agent 每次迭代都自主决定是调用工具还是给出最终答案。

4.2 Plan-and-Execute

Agent 先制定完整计划，再分步执行。典型流程：

Init 阶段：分析任务，生成 plan.md，分解为子步骤
Exec 阶段：按计划逐步执行，每步完成后更新进度
Check 阶段：验证结果是否符合预期，必要时回退或修正

这种模式的优点是任务可追溯、可断点续传。缺点是灵活性不如纯 ReAct——当实际情况偏离计划时，需要 Agent 具备"重新规划"的能力。

4.3 Tool-use 模式

专门优化工具调用的架构，关键要点：

工具名用动词短语：parse_resume、score_match，而不是 resume_tool、match
参数含正反面说明：告诉 LLM 什么情况下用什么参数
返回值结构稳定：格式可预测，方便 LLM 解析
工具隔离：每个 Sub-Agent 只装它真正需要的工具

4.4 MCP 协议

MCP（Model Context Protocol）是 Anthropic 提出的工具层标准协议。可以理解为 Agent 世界的 USB 协议——任何工具只要实现 MCP，就能即插即用。

“OneAgent + MCPs” 范式正在成为趋势：用一个统一的基础 Agent，通过不同领域的 MCP 服务器扩展能力，代替传统的"每个场景一个独立 Agent"的模式。

五、关键术语速查表

术语	一句话解释	程序员类比
Agent	能自主决定下一步做什么的 LLM	一个有 main loop 的微服务，每次迭代自己选路由
LLM	Agent 的"大脑"，负责推理和决策	一个超级强大的 if-else 引擎，输入是自然语言
Tool	Agent 操作外部世界的接口	微服务的 API endpoint，有 schema、参数、返回值
Memory	跨会话持久化知识	数据库（持久层）+ 缓存（上下文窗口）
ReAct Loop	基础执行循环	`while(true) { think → act → observe }`
Harness	把 Agent 装起来的"操作系统"	相比"怎么写"（Prompt），优化"怎么装"
Loop	自动触发 Agent 的循环系统	cron + event-driven 架构
Workspace	Agent 的"当前工作目录"	不是变量，是 git 仓库——每一步可回放、可审计
Verifier	检查 Agent 输出是否正确	断言之于测试
Skill	可复用的知识包	插件系统 + 懒加载库
MCP	工具层的标准协议	Agent 世界的 USB 协议

六、从哪里开始？

如果你是一个有编程基础的程序员，想开始实践 Agent 工程，以下资源值得关注：

一手信息源（英文，需网络环境）

来源	推荐理由
Lilian Weng, “LLM Powered Autonomous Agents”	Agent 入门圣经，系统讲工具调用、记忆、规划三大支柱
Anthropic, “Build Effective Agents”	官方最佳实践，简洁实用
Mitchell Hashimoto 博客	Harness Engineering 原创者
Boris Cherny, howborisusesclaudecode.com	Claude Code 之父，loop 实战
Addy Osmani Substack	Loop Engineering 提出者

国内可访问的中文资料

文章	来源	推荐角度
Agent Harness 工程实践	阿里云开发者	Harness 定义 + 四条铁律
Harness 工程之道：Skill 原理与最佳实践	阿里云开发者	渐进性披露、Skill 目录结构
Loop Engineering 四层模型	腾讯云开发者	四层嵌套框架（本文骨架来源）
OneAgent + MCPs 范式	阿里云开发者	Agent 发展四阶段模型
Boris Cherny 的 /loop 实战	歪脖抠腚	验证先行、CLAUDE.md 知识积累

七、结语

回到最核心的那句话：Agent = Model + Harness。

模型本身的能力固然重要，但工程落地的瓶颈往往不在模型够不够聪明，而在有没有把它装好。Prompt Engineering 只是起点，往上还有 Context Engineering（喂对信息）、Harness Engineering（装好系统）、Loop Engineering（自动化循环）——每一层都是值得深入的方向。

从今天开始，不妨试着用 Agent 的思维来思考问题：不是"让 AI 帮我回答这个问题"，而是"给 AI 一个目标、一套工具、一个自主决策的环境，让它自己去搞定"。

这才是 Agent 时代真正的编程范式转变。