Agent 基础与系统边界

先准确理解 Agent

任务、目标与能动性

任务描述需要处理的工作，目标把工作收敛为可验收结果，能动性则表示系统可以依据当前状态和新观察选择下一步。三者不能混用：一句“帮我处理退款”只是任务意图；“订单符合政策且退款业务状态进入成功或明确失败终态”才接近可验收目标。

Agent 的关键不是模型能生成多长的回答，而是模型是否参与控制后续过程。Anthropic 将 Agent 与 Workflow 的差异放在控制流上：Workflow 由预定义代码路径编排，Agent 让模型动态指导自身过程和工具使用；OpenAI 的实践指南同样把“由 LLM 管理工作流执行、判断完成并在失败时停止或移交”列为 Agent 的核心特征。Anthropic：Building effective agents，OpenAI：A practical guide to building agents。

构成 Agent 的最小要素

一个可运行的 Agent 至少包含四类责任：模型处理无法穷举的判断；指令说明任务、边界与停止方式；工具把模型连接到外部事实和动作；Runtime 组装上下文、执行工具、保存状态并控制循环。模型是决策组件，不是整个系统。

哪些系统不因此成为 Agent

聊天界面、单次模型调用、一次检索或固定顺序的多模型流水线都不自动构成 Agent。如果路径由代码提前确定，模型只在节点内分类、抽取或生成，这仍然是带 LLM 节点的 Workflow。反过来，Agent 也不要求无限自治；只要模型在受控行动空间内依据观察动态选择下一步，就已经具有 Agent 性。

从输入到终态的 Agent 闭环

Goal、State、Observation、Action

Goal定义期望终态和约束；State记录任务当前事实；Observation是执行动作或读取环境后得到的新信息；Action是系统允许选择的下一步。模型可见的 Context 只是 State 的一次投影，不是事实状态本身。订单是否已退款属于业务系统状态，模型上下文里出现“退款成功”不能改变它。

判断、行动、观察与重规划

ReAct 论文研究的是推理与行动交错：模型生成任务相关行动，行动接触外部环境并带回信息，后续判断因此更新。它提供一种理解循环的方式，不是生产 Runtime 的完整实现，也不意味着必须暴露或保存模型的私有思维链。可审计系统应保存计划摘要、工具提案、真实结果、状态变化和最终证据。ReAct 原论文。

一个循环只有在观察能够改变下一步时才有意义。如果模型无论工具返回什么都重复同一调用，这不是“自主推理”，而是失控循环。Runtime 应将观察转换为结构化状态，限制最大步数、时间和费用，并允许取消、等待和人工接管。

完成、失败、等待、取消与结果未知

生产系统不能只有“继续”和“完成”。至少需要区分完成、明确失败、等待外部输入、用户取消，以及无法确认外部结果的“结果未知”。最后一种状态尤其重要：若工具已执行但响应在回注前中断，系统不能将其简单标记为失败并重跑，否则可能重复退款或发送两封邮件。

Chatbot、Copilot、Workflow 与 Agent

用控制流归属区分系统

这些形态不是按 UI 区分，也不是非黑即白。最有解释力的问题是：谁决定下一步，谁执行动作，谁承担完成责任。

Hybrid 是生产系统的常见默认

Hybrid 不是折中失败，而是把不同类型的不确定性放给合适的责任主体。代码控制身份、权限、事务、预算和高风险步骤；模型处理意图理解、开放检索、候选计划和异常解释；人工处理偏好冲突、不可逆审批和责任性决定。

例如退款系统可用确定性 Workflow 固定“读取订单—校验租户—计算上限—审批—执行—核验”骨架，只允许 Agent 在政策文本、例外说明和补充材料中做开放判断。系统因此保留灵活性，又不把资金事务交给概率文本生成。

模型、工具、记忆、规划与环境

模型与指令

模型提供语言理解、生成、推理和选择候选动作的能力，指令则定义目标、可用信息、行为边界和无法完成时的处理。能力与权限必须分开：模型升级可以让候选计划更好，不应自动扩大数据访问和副作用范围；Prompt 可以表达政策，却不能替代服务端授权。

工具与环境

工具把模型的符号输出连接到环境。读取型工具获取事实，动作型工具改变外部状态，委派型工具把子任务交给其他能力。工具定义需要名称、描述、输入契约和结果语义；真正的身份、权限、幂等和审计由执行器负责。模型产生 Tool Call 只是行动提案。

Memory 与 State

State 回答“本次任务现在怎样”，Memory 回答“过去哪些信息值得以后检索”。对话历史只是输入材料之一。把所有历史原样塞回 Context 既不是可靠状态管理，也不是长期记忆：它会受到窗口、位置、冲突、隐私和陈旧信息影响。

Planner、Runtime 与 Harness

Planner 表示产生、分解或调整计划的能力；Runtime 负责循环、状态、工具执行、超时和恢复；Harness 是更宽的工程外壳，将模型、指令、Context、工具、状态、策略、日志和评测组合起来。三者是不同层次，不应把使用某个框架等同于拥有完整 Agent 系统。

自主性、授权与责任边界

从建议到受约束自治

自主性不是一个开关。系统可以从只读分析、生成建议、逐步确认，逐渐扩展到策略内自动执行；高风险、不可逆或受监管动作继续强制审批。自治等级应按动作风险和可验证性分别定义，而不是给整个 Agent 一个模糊标签。

四类授权预算

• 权限预算：可访问哪些数据、租户和工具。
• 运行预算：最大步骤、时间、并发与重试。
• 经济预算：Token、API、人工和副作用成本。
• 影响预算：单次与累计范围、可逆性和审批阈值。

预算之间不能相互替代。一个只能调用三步的 Agent 仍可能在第一步执行高风险动作；一个只读 Agent 即使循环很多次，也主要造成成本和隐私风险。系统要按故障后果组合控制。

责任不能委托给模型

业务 Owner 定义目标和风险容忍度，系统 Owner 负责技术控制，审批者对高风险决定负责，运行团队处理告警和事故。模型没有法律或组织责任，也不能成为审计链的最终主体。Anthropic 关于可信 Agent 的实践同样强调人类控制、透明、安全和隐私。Trustworthy agents in practice。

从理论进入用例判断

Agent 适用的组合条件

适用信号通常需要同时出现：目标清楚但路径难以穷举；任务需要在多个信息源和工具间协调；中间结果能够被检查、纠正或撤销；开放判断带来的收益足以覆盖额外延迟、成本和治理。只有“模型能回答”不是充分条件。

明确拒绝 Agent 的条件

规则能够完整表达、结果无法低成本验证、错误不可逆且不能审批、事实源缺失、延迟极严或监管要求固定流程时，应优先规则、Workflow 或人工流程。Anthropic 的工程建议是从最简单可行方案开始，仅在灵活性收益值得时增加 Agent 复杂度。

最小验收证据

一份可评审的用例判断至少包含：业务完成定义、控制流归属、为何不是纯 Workflow、自治等级、权限和预算、正常与受控失败 Trace、审批与降级路径、业务后置条件、残余风险和 Owner。没有这些内容，架构图上的“Agent”只是命名。