这个问题其实已经触及到 Agent系统设计的核心分歧。很多人感觉“Agent不好用”，但说不清原因。本质上是：大多数Agent架构是从“对话系统”演化出来的，而不是从“执行系统”设计出来的。

我分几个层次讲，会比较清晰。

一、为什么 99% 的 Agent 架构其实是错的

现在主流 Agent 框架，比如：

• LangChain
• AutoGPT
• CrewAI

基本都继承了一种架构：

User
 ↓
Prompt
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
Answer

看起来像这样：

Think → Act → Observe

这就是经典 ReAct 模式。

但问题是：ReAct只是一个推理模式，不是系统架构。

很多框架误以为：

Agent = ReAct loop

于是就出现了几个致命问题。

二、错误一：LLM 既当大脑又当调度器

大部分 Agent 系统是这样的：

LLM
 ├ 任务规划
 ├ 工具选择
 ├ 状态管理
 ├ 结果评估
 └ 决策

全部让 LLM 做。

这就相当于：

CPU
操作系统
调度器
程序

全部塞进一个函数里。

这是非常糟糕的架构。

原因是：

LLM 不是状态机。

它是：

stateless probability generator

也就是：

概率文本生成器。

它并不擅长：

• 长期状态管理
• 精确流程控制
• 复杂调度

于是 Agent 就会：

• 忘记任务
• 重复操作
• 死循环
• 跑偏

三、错误二：没有真正的“任务树”

绝大多数 Agent 的任务结构其实是：

task
  ↓
LLM分解
  ↓
执行

问题是：

没有显式任务结构。

真正复杂任务需要：

任务树

比如：

Build Web App
   ├ Design architecture
   ├ Setup project
   │    ├ init repo
   │    ├ install deps
   │    └ configure build
   ├ Implement API
   └ Deploy

但多数Agent没有这个结构。

它们是：

一步 → 下一步 → 下一步

线性的。

一旦某一步失败：

整个系统就迷路了。

四、错误三：没有独立的“评估器”

绝大多数 Agent 是这样：

LLM执行
LLM评估

例如：

Write code
→ Run test
→ LLM判断是否成功

这其实非常不可靠。

因为：

LLM会 自我欺骗。

它经常会说：

Yes the task is completed.

即使完全没完成。

真正可靠的系统需要：

Executor
Evaluator

分离。

例如：

code execution
test result
diff
linter

由系统判断，而不是 LLM。

五、错误四：没有“世界模型”

绝大多数 Agent 不知道世界状态。

例如：

文件系统。

很多 Agent 是这样：

LLM猜测文件内容

而不是：

读取文件
建立索引
维护状态

这导致：

• 修改错误文件
• 覆盖代码
• 破坏项目

六、真正正确的 Agent 架构应该是什么

更合理的结构其实更像 操作系统。

一个成熟 Agent 应该长这样：

                User
                  │
             Task Manager
                  │
              Planner
                  │
           ┌──────┴──────┐
           │             │
        Executor      Memory
           │
       Tool System
           │
        Evaluator
           │
          Loop

核心原则是：

LLM只负责智能推理。

而不是负责：

• 调度
• 状态
• 执行控制

七、Claude Code 可能的真实架构

虽然 Claude Code 没公开细节，但从行为上推测，大概结构类似这样：

User Request
     │
Task Interpreter
     │
High Level Planner
     │
Task Graph
     │
Execution Loop
     │
Tool Runner
     │
Environment State
     │
Evaluation

关键点有几个。

1 明确的任务循环

它不是一次性生成答案，而是：

Plan
Execute
Observe
Update Plan

持续循环。

2 强工具系统

Claude Code 的工具不是普通 API。

而是 操作系统级工具：

• bash
• git
• file edit
• search
• diff

这让它真正能：

操作真实项目

而不是只生成代码。

3 持久环境状态

它非常清楚：

当前 repo 状态
文件结构
git diff
命令输出

Agent 不会靠猜。

4 强约束策略

Anthropic 的 prompt engineering 极其强。

系统 prompt 很可能包含：

• coding guidelines
• error recovery
• tool usage policy
• step planning

这会大幅减少：

Agent失控

八、为什么 Anthropic 做 Agent 特别强

原因其实很简单：

Anthropic 从一开始就把 Claude 设计成：

tool-using model

而不是纯聊天模型。

他们很早就在研究：

LLM + tools
LLM + environment
LLM + constitution

所以 Claude 在：

• 长任务
• 工具调用
• 多步执行

这些地方非常稳。

九、未来 Agent 的真正形态

未来成熟 Agent 可能更像这样：

AI OS

里面有：

Planner
Executor
Memory
Evaluator
Tool Bus
World Model

LLM只是：

智能模块

而不是整个系统。