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内部“元工具”,负责:
-
创建子Agent,传子任务+受限工具 -
同步递归调用子Agent -
捕获 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探索。
五、 横向对比与选型建议
|
|
|
|
|
|
---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
选型决策树:
-
读密集+并行 → 多体协作 -
写密集+强一致 → 单体循环/事件驱动 -
混合型 → “并行读→顺序写”两阶段组合 -
需自愈/高鲁棒 → 事件驱动
六、 工程实践要点与落地建议
-
先问ROI,再谈多体:多体协作Token和工程成本高昂,务必确保任务业务价值覆盖。 -
先搞定上下文,再设计工具:LLM能否高效思考,首先取决于上下文质量。 -
先保障可观测性,再追求并行:复杂并行系统必须有完善日志、追踪和回放机制。 -
事件驱动架构需深厚分布式与状态机功底,适合有强大工程团队的场景。
七、 未来展望:窗口升级后的“大道至简”
|
|
---|---|
|
|
|
|
|
|
八、 结语
始于简单,归于简单,所有复杂只是通向更高层次简单的必经之路。
在可预见的未来,Agent系统仍需在“上下文匮乏”与“工程复杂度”之间披荆斩棘。选型的关键不在炫技,而在ROI、可观测性、容错需求。
愿本赏析文档为你打造下一代AI Agent系统提供一盏指路灯。