Augmented LLM

Augmented LLM 是在基础 LLM 周围接入 retrieval、tools、memory/context 等能力后的可执行模型构件；它扩大模型可获得的信息和可执行动作，但本身不等于具有长期自主控制循环的 Agent。

#ai #augmented-llm #concept #growing

[!info] related notes

所属 MOC: AI MOC, Agent MOC

基础模型: LLM

Tool 调用: Function Calling, MCP 协议, Built-in Tools

Memory: AI Agent Memory Layer

上层系统: Agentic Systems, Agent

Augmented LLM

一句话定义

Augmented LLM 是：

LLM
+ Retrieval
+ Tools
+ Context / Memory

形成的增强执行构件。

它让模型不仅依赖预训练知识与当前用户文本，还可以获取外部现场信息、调用真实工具，并使用跨步骤或跨会话状态。

Retrieval

Retrieval 解决：当前模型上下文中缺少哪些外部事实？

例如代码库搜索、文档搜索、企业知识、数据库查询、Web 搜索。

Retrieval 的结果最终仍要进入当前 Context 才能被模型使用。

Tools

Tools 解决：模型需要对外部世界执行什么能力？

例如读写文件、shell、API、浏览器、数据库、业务动作。

Function Calling、MCP、built-in tools 都可能成为工具接入层。

Memory / State

Memory 解决：哪些信息需要跨当前一次模型调用继续存在？

但要区分 conversation state、runtime state、durable business state 与 long-term memory，不能把所有持久化数据都叫 Agent memory。

最小执行链

User request
→ Build context
→ LLM reasons
→ maybe retrieve
→ maybe call tool
→ observe result
→ LLM continues
→ final output

为什么它还不一定是 Agent

增强能力不自动产生 autonomy。

完整 Agent 往往还需要：

goal/task state；
multi-step execution loop；
stop condition；
retry/recovery；
permissions；
approval；
trace；
durable state。

因此：

Augmented LLM
= Agent 的常见 building block

Agent
= Augmented capability
  + control loop
  + runtime/state/governance

“工具越多越强”为什么不成立

每个新增工具都会增加 tool selection ambiguity、schema/token cost、permission surface、error modes 与 observation noise。

所以能力设计应优先：

clear contract
→ minimal useful capability
→ observable result
→ permission boundary

而不是堆工具数量。

Retrieval、Tool、Memory 的边界

能力	核心问题
Retrieval	我还需要知道什么？
Tool	我需要执行什么？
Memory	哪些过去信息未来还要用？
Context	这一次模型调用真正看到了什么？

它们可能共享底层存储或协议，但语义不同。

学习检查

不看正文回答：

Augmented LLM 比裸 LLM 多了哪几类能力？
Retrieval 与 Memory 为什么不是同一个概念？
Tool result 为什么最终仍需要进入 Context 才能影响后续推理？
为什么有 tools 的 chatbot 仍不一定是 Agent？
完整 Agent 相比 Augmented LLM 还需要哪些 control/runtime 能力？
为什么增加更多 tools 可能降低而不是提高系统质量？
给一个 coding assistant，把 retrieval、tool、memory、runtime state 分别映射到真实组件。