Agent 系统的数学语言：从状态空间到 MCP、Memory 与 Multi-Agent

Primer

① 先把后文会反复出现的词认清楚

规则：先知道术语是什么，再用它们做综合判断。卡片收起时就能看到一句话直觉；需要严格定义、边界和案例作用时再展开。

本课先认词：数学对象用数学样式，代码标识符才用 code。下面 16 组概念覆盖一个生产 Agent 的核心对象。

Agent目标驱动、观察—决策—动作—反馈的闭环。

形式化为 $𝒜=(𝒢,𝒮,𝒪,𝒞,π θ,𝒦,𝓜,𝓡,τ)$ 。Model 只是策略核心，Agent 是完整运行系统。

Goal / Instruction目标与语言层规则。

$g \in𝒢$ ；目标可写成约束下最大化效用 $U (g, s T)$ 。Prompt 规则不是权限。

Model / Policy把 Context 映射成下一动作分布。

$a t \simπ θ (\cdot| c t, g)$ 。模型提出候选动作，不代表已执行。

State / Observation / Context真实状态、可见投影、模型输入。

$s t \in𝒮$ ， $o t = O (s t)$ ， $c t = C (g, I, H t, R M (q t), o t)$ 。

Message / Turn / Run事件、逻辑交互、完整执行轨迹。

$m i =(type,payload,meta)$ ；Turn 可含多个模型/工具事件；Run 是轨迹 $ρ=(c 0, a 0, o 1,\dots, o T)$ 。

Thread / Session事件链与状态作用域。

Thread 可写 $Θ=(m 1,\dots, m n)$ 或 DAG；Session 可写 $Σ=(id, H,meta)$ 。二者没有跨框架统一包含关系。

Memory / RAG / Source of Truth历史状态、外部检索与真实系统状态。

Memory 可写 $𝓜=(Store,W,R,U,F)$ ；RAG 从外部数据集合检索；线上版本、余额等动态事实优先查 Source of Truth。

Tool / Schema / Structured Output动作函数与机器可验证输入输出。

工具 $f i : D i \to Y i$ ；Schema 只定义结构合法域，不等于授权。

MCP Host / Client / Server把 Tools、Resources、Prompts 标准化接入 Host。

$Host=(Runtime,{Client j},Policy,UI)$ ；Server 暴露能力集合。Host ≠ Agent ≠ Client，Resource ≠ Memory。

Runtime / Runner真正执行循环、分发工具并管理状态。

$Runner:(Agent,input,state)\toRunResult$ ，负责 tool dispatch、streaming、interruption、session、budget 与 termination。

Guardrail / Authorization / Approval / HITL把候选动作缩成真实可执行动作。

$Guard(x, c)\in{0,1}$ ， $Auth(u, r, a, c)\in{0,1}$ ；HITL 在高风险边界暂停、批准或拒绝。

Workflow / Orchestration预定义控制图与组件调度。

Workflow 可写 $W =(Q, E,δ, q 0, F)$ ；Agent 则由策略在运行时开放选动作。

Planning / Replanning显式计划与基于新观察的重规划。

计划 $p t =(a t,\dots, a t+k)$ ；新 observation 到来后再 Replan。无需暴露隐藏推理链。

Multi-Agent / Handoff / Agent-as-Tool多个策略节点协作。

协作图 $G =(V, E)$ ；Handoff 切换 active agent；Agent-as-Tool 让 manager 调 specialist 后继续控制。

Retry / Timeout / Idempotency / Sandbox副作用与失败控制。

理想幂等满足 $T (T (s, a), a)= T (s, a)$ 。Timeout 不代表服务端未执行；Sandbox 限制可达状态与能力。

Trace / Hooks / Eval / Budget运行证据、生命周期回调与目标函数。

Trace 记录 model/tool/handoff/approval span；Usage 统计 tokens/calls/cost/latency；Eval 联合成功、成本、延迟与风险。

我能区分 Agent 的状态、能力、控制与协作概念。

Orient

② 现在再看这段材料到底在说什么

核心定义：Agent 是一个受约束的部分可观察动态决策系统。

o t = O (s t), c t = C (g, H t, M t, o t), a t \sim π θ (\cdot| c t, g), s t+1 = T (s t, a t)

LLM 主要实现策略；Session / Memory 管状态；Tool / MCP 管能力；Schema / Guardrail / Authorization / Approval 管可执行域；Runner 执行循环。

最小 Agent

Observation + Policy + Action + Feedback/Termination。

工具型 Agent

动作会读写外部环境，新 observation 改变下一步。

生产 Agent

再加入权限、审批、预算、幂等、沙箱、Tracing 与 Eval。

我能用九元组和状态转移解释 Agent。

Connect

③ 概念关系与最小知识闭包

1 · 五层模型

层	数学对象	Agent 概念
决策	$π θ (a \| c, g)$	Model、Instruction、Planning、Tool Choice
状态	$m, Turn, ρ, Θ, Σ, 𝓜$	Message、Turn、Run、Thread、Session、Memory、Context
能力	$𝒦={f i : D i \to Y i}$	Tool、Structured Output、MCP、Resource、Prompt
控制	$A exec \subset A$	Schema、Guardrail、Authorization、Approval、Sandbox、Retry
观测	$Trace, Usage, J$	Hooks、Observability、Eval、Budget

2 · 可执行动作是约束交集

A exec = A schema \cap A enabled \cap A guard \cap A auth \cap A approval \cap A invariant

Schema 只保证参数形状；最小权限、Guardrail、Authorization、审批与业务不变量继续缩小动作空间。

3 · 状态层级

Message

最小事件。

Turn

一次逻辑交互，可含多次模型/工具调用。

Run

Runner 的一次完整轨迹。

Thread

事件顺序/因果链。

Session

跨 run 的状态作用域。

Memory

跨时间写入、检索、更新和遗忘机制。

4 · Workflow vs Agent

Workflow: q t+1 = δ(q t, e t) Agent: a t \sim π θ (\cdot| c t, g)

Script 是固定序列；Workflow 是程序员预定义 DAG/状态机；Agent 在运行时依 context 选动作。生产中常用“Workflow 外壳 + Agent 节点”。

5 · Multi-Agent

令 $G =(V, E)$ 。Handoff 令活跃策略切换到 specialist；Agent-as-Tool 把 specialist 封装成子函数，manager 拿回结果后继续。

十条式子抓住全景

观察	$o t = O (s t)$	模型只见状态投影。
上下文	$c t = C (g, I, H t, R M, o t)$	Context 是构造结果。
策略	$a t \simπ θ (\cdot\| c t, g)$	Model 是决策器。
工具	$f i : D i \to Y i$	Tool 是动作函数。
转移	$s t+1 = T (s t, a t)$	动作改变环境。
Session	$Σ=(id, H,meta)$	工作状态作用域。
Memory	$𝓜=(Store,W,R,U,F)$	跨时间读写。
Workflow	$W =(Q, E,δ, q 0, F)$	预定义控制图。
协作	$G =(V, E)$	Multi-Agent 图。
Eval	$J =E[U -λ C -μ L -ν R]$	成功、成本、延迟、风险联合优化。

图解 · Pages 原生结构图 一次 Agent 动作里，MCP、Memory 与参数约束分别在哪一层发生作用？

从左到右看一次动作：先组装上下文，再让模型选动作；注意 Schema 与 Runtime Policy 是两个不同关口，最后才到 MCP/工具执行与结果回流。

① 组装 Context

用户输入 + 当前 Session 历史 + 检索到的长期 Memory，组成这一轮模型真正能看到的上下文。

② 模型选择下一步

模型可以直接回答，也可以选择一个本地工具或由 MCP 暴露的工具，并生成结构化参数。

③ Tool Schema 收窄参数

required、enum、范围、格式等约束先回答“参数长得是否合法”，不负责判断调用者有没有权限。

④ Runtime Policy 决定能否执行

Guardrail、审批、Authorization、资源状态与幂等性继续回答“这一次动作是否真的允许发生”。

⑤ MCP / 本地工具执行

通过检查后，Host 才把调用交给对应的 MCP Server 或本地函数；协议只负责接能力，不替代业务正确性。

⑥ 结果回流并选择性写 Memory

结构化结果重新进入模型上下文；完成任务后，只把未来仍有价值的事实、偏好或经验写入长期 Memory。

结论：Memory 决定什么历史进入当前上下文，模型决定下一步意图，Tool Schema 先限制参数形状，Runtime 再做授权与业务检查，MCP/本地工具只执行已经通过这些边界的调用；工具结果随后回流，并且只有值得未来复用的信息才写入长期 Memory。

边界：这是教学用运行环，不等价于某个 SDK 的内部调用栈；具体实现可以合并或拆分步骤，但不能把参数校验当成授权，也不能把 MCP 当成 Memory。

Reconstruct

④ 把真实案例重新还原

统一案例：定位未知部署失败

goal = 修复部署失败
production deploy 需要人工审批
max_model_turns = 12
cost ≤ B

Step 1 · Host 与能力

$Host=(UI,Runtime,Clients,Policy)$ 。Repo / CI / Deploy MCP Server 暴露工具与资源；诊断阶段只启用 $K t \subset K all$ ，先隐藏 production 副作用工具。

Step 2 · Session / Memory / Context

Session 保存当前历史；Durable Memory 可检索“production release requires approval”；当前线上版本仍查 Source of Truth。

Step 3 · Loop

Agent 先 read_ci_log，得到 dependency mismatch，再读 lockfile、修改并跑测试。新 observation 改变下一步，形成闭环。

Step 4 · 执行边界

environment ∈ {staging, production}
canary_percent ∈ [1,25]
Auth(user, production, deploy)=1
Approval(call_id)=approved

Schema 合法仍不够；服务端还要检查身份、资源状态、审批、幂等与业务不变量。

Step 5 · 失败与恢复

Timeout 不证明服务端没执行；副作用要有 operation/idempotency key。需要 HITL 时序列化 RunState，批准/拒绝后恢复。

Step 6 · Trace / Eval

Trace 记录 model、tool、handoff、guardrail、approval 等 span；Eval 比较成功率、成本、P95 latency、风险与人工介入。

我能把真实 Agent 任务写成状态、策略、动作与约束。

Map

⑤ 概念如何映射到现实

普通软件概念 ↔ Agent 数学位置

词	数学位置	关键边界
Host	$(Runtime,Clients,Policy,UI)$	承载 Agent 应用，不等于 MCP Client。
Client / Server	消费者 / 能力提供者	MCP 只是其中一种协议。
Thread	$Θ$	消息/事件链，不是 CPU thread。
Session	$Σ$	状态作用域，不等于长期 Memory。
Workflow	$δ(q, e)$	控制流主要预定义。
Agent	$π θ (a \| c, g)$	开放动作选择由策略在线决定。

MCP / RAG / Memory

MCP 把 Tool / Resource / Prompt 暴露成标准能力；RAG 从外部数据源检索；Memory 是 Agent 自己的历史状态机制。三者都能影响 Context，但不是同一对象。

Planning / Parallelism / Security

Plan 可以被新 observation 重写；独立只读工具可并行；副作用若不可交换就需顺序/事务。外部文档和 Tool output 是不可信数据，不能通过 prompt injection 提升权限；Sandbox 与 capability policy 限制可达资源。

生产目标函数

J (π) = E [U -λ C cost -μ L latency -ν R risk]

因此“模型更强”不自动等于系统更好；工具筛选、Memory precision、缓存、权限设计、减少无效 handoff 也会改变系统价值。

Attempt

⑥ 现在把它当成一道题

1Agent vs Workflow

给“固定发布链”和“未知故障诊断”分别写出 δ 或 πθ，并设计混合结构。

2Thread / Session / Memory

分别定义 Θ、Σ、Durable Memory，并举一个不能互换的例子。

3动作可行域

Schema 允许 production，但用户无权限。指出动作在哪个谓词被拒绝。

4MCP

Server 同时暴露 read_repo 与 delete_branch。只读任务应该给模型看哪个能力集合？

5Multi-Agent

用 triage / coder / reviewer 比较 Handoff 与 Agent-as-Tool 的控制权。

6Eval

为什么没有 λ、μ、ν 和风险函数，就不存在数学上唯一的“更好 Agent”？

你的作答

我已经完成自己的第一版作答，再进入提示。

Hint → Answer

⑦ 分级提示，最后就是实际答案

Hint 1 · 方向

先判断问题属于状态 S/M、能力 K/A、允许 R、策略 π 还是终止 τ。

Hint 2 · 结构

Thread ≠ Session ≠ Durable Memory
A_exec ⊆ A_schema ⊆ A
Workflow: q_next = δ(q,event)
Agent: action ~ πθ(.|context,goal)