Agents

条目状态与系统位置

本图主要位于 Agent Runtime，并向上连接 Serving/API、向下连接 Model/Inference。可点击条目是独立文章；“未单列”表示由现有 Agent Loop、State 或 RAG 文章覆盖；“待建”才表示真正缺少正文。

学习主线

先掌握 Agent Loop 的 state→action→observation，再进入 API 状态、工具可靠性、记忆/RAG、评测和上线。多 Agent 与 Agentic RL 都是后续分支，不应跳过单 Agent 的失败分类。

核心循环

Agent Loop
Agent State and Model APIs
state、action、observation、termination（未单列：见 Agent Loop）

工具与控制

Tool Calling、schema、validation、timeout、retry、idempotency（未单列：见 Agent Loop）
ReAct、planning、plan-and-execute、reflection（待建：目前只有 Agent Loop 中的控制方式比较）
structured output 与 human-in-the-loop（待建）

记忆与上下文

short-term state（未单列：见 Agent State and Model APIs）
long-term memory（待建）
context engineering（未单列：见 Agent State and Model APIs）
inference request、conversation state 与 reasoning state 的边界（未单列：见 Agent State and Model APIs）
Agentic RAG

Multi-Agent

role、message、shared state、handoff、conflict handling（待建）
多 Agent 不是目标本身；需要证明分工收益大于通信与编排成本

上线与安全

session、concurrency、checkpoint、long-running tasks（未单列：运行时上线清单）
permissions、prompt injection、data leakage、tool misuse（未单列：安全边界清单）
trace 与 Agent Evaluation
MOC - Serving and LLMOps

训练闭环

运行时 Agent 工程不等于 RL。
rollout、trajectory reward、learner 和 weight synchronization 进入 MOC - Agentic RL。

决策边界

单轮问答
→ 需要外部事实？接 RAG
→ 需要动作/反馈？接工具循环
→ 需要长期任务？加持久 state/checkpoint
→ 需要从轨迹学习？进入 Agentic RL

每增加一层，都增加状态、失败面和可观测性成本。先证明工具调用、恢复和评测的收益，再引入多 Agent 或在线 RL。

按任务形态选择运行时

任务需要	最小系统	何时继续加复杂度
只需一次外部事实	普通调用或单次 RAG	证据需要多跳且中间实体可验证
有一个确定动作	单工具调用 + schema/权限门	动作结果会改变下一步计划
多步且可恢复	Agent Loop + durable state/checkpoint	任务跨进程、跨天或有多个负责人
多角色并行	明确 shared state 与 handoff 的多 Agent	角色分工能在固定集上降低失败或成本
从轨迹改进策略	rollout/verifier/learner 的 Agentic RL	运行时评测已稳定，奖励可辨识

调试顺序

出现“Agent 不可靠”时，先在 trace 中找最后一个正确的状态转移：工具是否收到正确参数，观察是否完整写回，压缩是否删除了约束，还是模型在正确状态上选择了错误动作。这个顺序把问题分到 schema、environment、state、policy 和 termination，而不是把所有失败归咎于 prompt。每个 MOC 分支都应回到 Agent Evaluation 的可判定任务和 Agent State and Model APIs 的状态边界。