LLM（大语言模型）与Agent的

核心矛盾在于：

“任务所需信息量” > “模型可持有上下文窗口”

当LLM的上下文窗口有限（如1M tokens），Agent系统必须通过外部“上下文管理策略”来弥补记忆短板。四大范式正是为此而生。

一、 单体线性循环：极简可靠的工匠范式

系统轮廓

+------------------------------------------------+
| Global Context (全局上下文)                    |
|  用户输入 / 思考串 / 工具调用 / 工具结果 ...    |
+------------------------------------------------+
        ↓ 读 & 写
+------------------+   调用   +--------------+
|   LLM 大脑       | ───────▶ | Tool 执行器 |
+------------------+   结果   +--------------+

• 唯一存储：GlobalContext
• 循环核心：ReAct（Reason → Act → Observe）
• 所有历史：线性追加，LLM每次都读全量

机制详解

• 每轮循环，LLM读取全部历史，输出“思考”与“工具调用”。
• 工具执行后，结果追加回上下文，供下一轮推理。
• 任务完成由FinishTool显式标记。

内部伪代码

ctx = ["用户: 做一杯咖啡"]
for _ in range(10):
    output = llm(ctx)
    thought, tool, params = parse(output)
    ctx += [f"思考: {thought}"]
    if tool == "Finish": return params["result"]
    obs = executor(tool, params)
    ctx += [f"观察: {obs}"]

亮点 & 缺陷

适用场景：短链路、强一致性任务、教学演示。

二、 层级式委托：任务分解的项目经理

系统轮廓

主 Agent (Project Manager)
    │ 调用 AgentTool
    ▼
子 Agent (Expert)  ← 隔离上下文 Sandbox

• AgentTool：主Agent内部“元工具”，负责：

1. 创建子Agent，传子任务+受限工具
2. 同步递归调用子Agent
3. 捕获FinishTool结果写回

机制详解

• 主Agent分析任务，决定委托，生成子任务与工具权限。
• 子Agent在全新上下文沙箱中运行，完成后通过FinishTool返回结果。
• 主Agent同步等待，结果写回主上下文。

内部伪代码

if tool == "AgentTool":
    sub = Agent(...)
    result = sub.query(task=subtask, ctx=[], tools=sub_tools + ["Finish"])
    ctx += [f"观察: 子任务完成 -> {result}"]

亮点 & 缺陷

适用场景：多文档串行分析、独立子问题深度钻研。

三、 多体协作：并行帝国

系统轮廓（ASCII）

                ┌── Worker A ──┐
用户请求 ─▶ 指挥官 O ─┼── Worker B ─┤→ 摘要 B
                └── Worker C ──┘
                     ...           → 摘要 A/C...
                      ↑
                (异步收集 & 综合)

• 核心武器：任务委托书 Task Prompt
• JSON精确指明domain/expected_output/constraints…

机制详解

• 指挥官Agent分解任务，生成详细“任务委托书”，异步分发给多个Worker Agent。
• Worker在独立上下文中并行处理，产出精炼摘要。
• 指挥官收集所有摘要，综合生成最终报告。

伪代码片段

{
  "worker_id": "researcher_pharma_001",
"task_domain": "AI in Pharmaceutical R&D",
"assigned_sub_task": "Investigate and summarize...",
"expected_output_specs": {
    "format": "Markdown",
    "max_length_words": 700
  },
"suggested_tool_priority_list": [
    "PubMedSearchTool",
    "ArxivSearchTool"
  ],
"constraints_and_exclusions": [
    "Exclude company stock news."
  ]
}

亮点 & 缺陷

适用场景：大规模信息搜集、并行研究、低依赖广度优先任务。

四、 事件驱动混合：自愈的数字工厂

总览框图

┌───────────────┐   发布指令   ┌────────────┐
│ 认知核心 LLM  │ ───────────▶ │ 事件总线 EB │
│ (Planner)     │ ◀─────────── │ (Pub/Sub)   │
└───────────────┘   反馈事件   └────────────┘
           │ 更新世界模型
           ▼
  Persistent World Model (DB)

事件总线 ⇄ 多 Actor (Shell / File / Browser / ...)

机制详解

• 认知核心（LLM）负责规划、决策，所有状态持久化于外部世界模型（DB）。
• 通过事件总线异步分发指令，Actor并发执行，结果事件反馈回认知核心。
• 遇到错误，LLM自动诊断并生成修复子计划，实现自愈。

核心循环伪代码

loop:
    plan = cognitive_core.plan(world_model)
    for action in plan.ready():
        EB.publish(action)
    for event in EB.consume():
        world_model.update(event)
        if event.is_error:
            repair_plan = cognitive_core.diagnose_and_fix(event)
            world_model.inject(repair_plan)

亮点 & 缺陷

适用场景：端到端复杂任务、7×24自主运维、AGI探索。

五、 横向对比与选型建议

选型决策树：

• 读密集+并行 → 多体协作
• 写密集+强一致 → 单体循环/事件驱动
• 混合型 → “并行读→顺序写”两阶段组合
• 需自愈/高鲁棒 → 事件驱动

六、 工程实践要点与落地建议

1. 先问ROI，再谈多体：多体协作Token和工程成本高昂，务必确保任务业务价值覆盖。
2. 先搞定上下文，再设计工具：LLM能否高效思考，首先取决于上下文质量。
3. 先保障可观测性，再追求并行：复杂并行系统必须有完善日志、追踪和回放机制。
4. 事件驱动架构需深厚分布式与状态机功底，适合有强大工程团队的场景。

七、 未来展望：窗口升级后的“大道至简”

八、 结语

始于简单，归于简单，所有复杂只是通向更高层次简单的必经之路。

在可预见的未来，Agent系统仍需在“上下文匮乏”与“工程复杂度”之间披荆斩棘。选型的关键不在炫技，而在ROI、可观测性、容错需求。

愿本赏析文档为你打造下一代AI Agent系统提供一盏指路灯。