Agent 的最小构成
一句话收获：Agent = LLM + 上下文 + 工具；Harness 让它成为受控系统。
这个场景在解决什么问题
这个场景要讲清一个 Agent 到底由哪几块拼起来：LLM（大语言模型，负责判断）、上下文（负责"能看到什么"）、工具（负责"能做什么"）、环境反馈（负责"下一步怎么变"）。
观察方式是"逐项加入判断能力、观察空间、动作空间和环境反馈"——一块一块往上加，看一个普通模型怎么一步步变成一个 Agent。它的价值在于：搞懂最小构成，才知道"缺了哪块就不算 Agent"，以及为什么要 Harness（约束框架）来兜底。
先理清这条判断链（文字版）
判断一个 Agent 是否成形，按这条链逐项看四块拼图：
- 先看有没有 LLM 提供判断：它能不能理解目标、生成回答或行动候选？（第 1 步：LLM 提供判断）
- 再看上下文有没有形成观察空间：目标、规则、状态、知识、工具说明进没进工作包？（第 2 步：上下文形成观察空间）
- 再看工具有没有形成动作空间：读、算、写、协作的能力给没给够？（第 3 步：工具形成动作空间）
- 最后看环境反馈有没有改变下一步：工具结果进没进下一轮，系统能不能决定继续/停止/接管？（第 4 步：环境反馈改变下一步）
一句话串起来：先看判断（LLM）→ 再看观察（上下文）→ 再看动作（工具）→ 最后看闭环（反馈 + 停止）。四块齐了、能闭环，才谈得上 Agent。
逐层详解
第 1 步：LLM 提供判断
原文：模型理解目标并形成回答或行动候选。
白话：LLM 的核心职责是"开放语义的理解 + 候选生成"——它能读懂模糊的目标，然后生成一个回答、或者一个行动候选。但它只负责"提"，不负责"做"。
类比：LLM 是"出主意的大脑"——它负责想、负责判断"该怎么办"，但真正动手的是后面接的工具。
举例：一个客服 Agent，LLM 读懂了用户"我的订单怎么还没到"，然后生成一个行动候选：先查订单状态。但它自己不去查，只是提出"该去查状态"这个候选。
为什么重要：开放语义和候选生成是 LLM 的主要职责——它擅长"理解 + 提方案"，这是它的价值所在。
怎么验证（证据点）：
- 目标已理解
- 候选已生成
- 仍未执行
别踩的坑（边界）：模型判断不能替代权威事实和权限——模型觉得"该退款"，不代表事实允许退款、也不代表它有退款权限。
落地检查：LLM 负责候选，不独占系统责任——LLM 只出候选，最终的事实和权限要由外部系统兜底，责任不能全压在模型身上。
第 2 步：上下文形成观察空间
原文：当前目标、规则、状态、知识和工具说明进入工作包。
白话：Agent 只能依据"当前能看到的"来判断。上下文把当前目标、规则、状态、知识、还有工具说明一起装进工作包，这些共同构成它的"观察空间"——它能看到什么。
类比：观察空间是"眼前能看到的一切"——你面前摆着什么资料、什么规则、什么工具说明，就决定了你只能基于这些来做判断。
举例：客服 Agent 的工作包里，装着"本次目标是解决催单"、"规则是超过 48 小时未发才可催"、"当前订单状态"、"可用的查询工具说明"。它只能基于这些信息判断下一步。
为什么重要：Agent 只能依据当前能看到的信息判断——看不到的，它就没法用。
怎么验证（证据点）：
- 信息来源明确
- 当前状态存在
- 权限范围匹配
别踩的坑（边界）：观察空间越大不一定越好——塞太多无关信息，反而会干扰判断、稀释重点，不是越大越强。
落地检查：观察空间要充分、相关并可追溯——既要给够，又要相关，还要能说清每条信息从哪来。
第 3 步：工具形成动作空间
原文：系统提供读取、计算、写入和协作能力。
白话：光会想、光能看到还不够，还得"能做"。工具把"行动意图"连接到外部程序，提供读取（查）、计算（算）、写入（改）、协作（配合别人）这些能力，共同构成"动作空间"——它能做什么。
类比：动作空间是"手边能用的家伙"——有查账本（读）、有计算器（算）、有签字盖章（写）、有能对接同事（协作），才真正能办事。
举例：客服 Agent 被授予三个工具：查订单接口（读）、算退款金额（算）、发起退款接口（写）。它就能从"看懂问题"变成"真能解决问题"。
为什么重要：工具把行动意图连接到外部程序——它是"想法"变成"动作"的接口。
怎么验证（证据点）：
- 可用工具明确
- 权限可检查
- 副作用可说明
别踩的坑（边界）：工具可见不等于工具可无条件执行——看得见"退款工具"，不代表随时能无脑调它，还要过权限和校验。
落地检查：动作空间必须足够且受控——工具既要给够、能办成事，又要受控、别乱用。
第 4 步：环境反馈改变下一步
原文：工具结果进入下一轮判断，系统决定继续、停止或接管。
白话：这是 Agent 的关键一环——工具执行后的结果，要回到下一轮判断里，系统根据这个反馈决定：继续干、停下来、还是转交人接管。下一步随观察变化而变化。
类比：环境反馈是"看一步走一步"——像下棋，走完一步看看对手的反应（反馈），再决定下一步怎么走，而不是闭眼按剧本走到底。
举例：客服 Agent 查订单状态，反馈"已发货"，它判断"无需催单，回复用户即可，停止"；如果反馈"未发货且已超 48 小时"，它就"继续下一步：发起催单"。
为什么重要：Agent 的关键是后续行动随观察变化——会"根据反馈改下一步"，才区别于死板的脚本。
怎么验证（证据点）：
- 外部结果进入
- 状态已更新
- 出口可判断
别踩的坑（边界）：循环多轮不自动成为可靠 Agent——转了很多圈，不代表方向对、结果可靠，可能只是在空转。
落地检查：真实反馈和停止机制共同闭合 Agent——既要有真实的环境反馈进来，也要有明确的停止/接管出口，两者一起才能"闭环"。
落地可行性小结
本场景涉及的技术栈：LLM（大语言模型）、上下文（Context）、工具（Tool/Function calling）、Harness（约束框架，负责上下文、工具、权限、状态、验证、恢复）。
真实落地怎么做：把 Agent 拆成四块——LLM 出候选、上下文定观察空间、工具定动作空间、环境反馈 + 停止机制形成闭环；再用 Harness 把这四块框在一个受控边界里。
要检查什么：目标是否被理解、候选是否生成、观察空间是否充分相关可追溯、工具是否明确且受控、反馈是否真实进入下一轮、停止/接管出口是否明确。
常见坑：把模型判断当成权威事实；观察空间一味堆大；工具给了就不加权限校验；只有循环没有停止机制，空转。
回顾
- Agent = LLM + 上下文 + 工具，四块拼图：判断、观察、动作、反馈。
- LLM 负责理解目标、出候选，不独占系统责任。
- 上下文形成观察空间，要充分、相关、可追溯，不是越大越好。
- 工具形成动作空间，要足够且受控，可见≠可无条件执行。
- 环境反馈 + 停止机制共同闭合 Agent，循环多轮≠可靠。
- Harness 负责上下文、工具、权限、状态、验证、恢复，让 Agent 成为受控系统。