Agent的本质：局限、组件模型与形态

Agent 的自主性，体现在它能在多大范围内自行选择动作、如何处理反馈，以及何时把控制权交回。模型能力是其中一个因素；权限、任务状态、执行时限与恢复机制同样决定系统能承担什么工作。

上一篇建立了五类职责与阅读地图。本文继续使用“调查订单异常”的场景，把职责落到配置、自主性边界、成本和业务执行上。文中的 A1–A4 是本系列的讨论框架，不是产品评级或行业标准。

1. 五类工程问题不等于模型的五种绝对缺陷

原始模型推理与完整产品需要分开看。常规推理不会因为一轮对话自动更新模型权重，但上下文、推理缓存和服务端会话都可能保存信息。模型能提出计划、修订答案和表达不确定性，只是这些输出不能自动成为可靠的业务状态。

“模型说已完成”与“系统确认已完成”之间，需要一条证据链。在订单调查里，模型可以解释支付记录，但付款是否成功应来自支付系统；如果查询超时，只能记录结果未知。

同样，模型的自报置信度不是校准后的成功概率。它可以作为待验证的信号，不能直接替代权限检查或决定高影响操作。

2. 把职责写成可执行的配置契约

下面是说明性的应用配置，不对应某家 SDK。字段要由运行时真正读取并执行；写在配置文件中并不会自动生效。

{
  "name": "order-investigator",
  "model_profile": "reasoning-default",
  "memory": {
    "conversation_enabled": true,
    "task_state_enabled": true,
    "cross_task_memory_enabled": false
  },
  "tools": [
    "query_order",
    "query_payment_status",
    "query_order_events"
  ],
  "planner": {
    "mode": "react"
  },
  "runtime": {
    "max_model_steps": 12,
    "max_tool_calls": 20,
    "deadline_seconds": 120,
    "token_budget": 30000,
    "consecutive_error_limit": 3
  },
  "policy": {
    "action_scope": "read_only",
    "identity_source": "authenticated_session"
  }
}

这些数字只是配置示例，需要根据任务长度与评估结果调整。把工具调用数和模型步数分开，是因为一次模型响应可能包含多个调用。

这个 Agent 只能调查，不能退款。身份来自已认证会话，不能由模型自由指定另一个用户；读取支付记录也必须经过服务端授权。后续如果新增处理能力，应单独定义业务操作与审批范围，而不是把只读配置改成“允许所有工具”。

五类职责可以由一个进程实现。Memory 不必一开始就接向量库，Planner 不必独立部署，Runtime 也不等于一个完整平台。

3. 决策输出可解析，还要可验证

程序需要明确知道模型是在请求工具、回答用户，还是等待补充信息。可以使用供应商原生工具调用，也可以定义应用层决策结构。下面是后者的一次实例：

{
  "action": "call_tool",
  "tool": "query_payment_status",
  "arguments": {
    "order_id": "O202512050001"
  },
  "reason_summary": "订单未确认，需要核对已有支付请求的最终状态"
}

reason_summary 是简短决策说明，不是模型内部推理的完整记录，更不是动作正确性的证明。

校验需要分层进行：

1. 解析与结构检查：动作类型是否合法，必填字段是否存在，是否出现多余字段
2. 动作匹配：请求工具时必须有工具名和参数，回答时必须有回答内容
3. 工具契约：工具是否已注册，参数是否满足该工具的 Schema
4. 授权与业务条件：当前主体能否查看这笔订单，该操作是否仍然允许
5. 结果判定：收到的是成功、拒绝、待处理还是未知状态

结构化输出减少格式歧义，不保证事实正确或业务合法。Schema 中写一段“调用工具时填写参数”的描述，也不能代替实际的条件校验。

4. A1–A4 描述控制权，不代表成熟度

A1 是用于比较的基线，未必会被所有定义称为 Agent。A2 与 A3 也没有固定的“3 轮”分界，同一产品可以同时提供不同形态。

A4 不意味着系统可以自行扩大业务目标或权限。持续运行需要任务归属、调度、持久化、取消、预算与恢复；新增子目标仍应服务于已经授权的目标。长期自动化也不要求每次都调用模型。

因此，不能把某个产品永久归为某一级，再据此断言它的成本或可靠性。应描述具体功能、版本与部署方式。模型改进可能让同一架构完成更多任务；架构改进也可能让同一模型更稳定地执行。

5. 何时值得增加动态决策

选择 Agent 前，先建立一个能比较的简单基线。订单状态查询通常可以由固定流程完成；异常调查如果经常需要根据新证据选择不同查询，才更可能从动态决策中获益。

输入需要语义理解，不等于整个任务都要交给 Agent。反过来，一个有确定状态机的业务，也可能包含值得使用 Agent 的解释、调查或方案生成环节。

规则引擎和普通代码也有开发、运行与维护成本，不能称为“零成本、100% 无错”。它们的优势是把已知规则明确执行，便于测试和审计。

6. 成本要按完整任务计算

全量重发历史时，输入 token 会累积。假设每轮有固定前缀 S，且第 i 轮的动态历史恰好是 i×T，则 N 轮输入为：

总输入 token = N×S + T×N×(N+1)/2

例如 S=2000、T=1000、N=5，合计 25000 输入 token。这个算例只描述特定上下文策略，不是所有 Agent 的成本规律；摘要、检索、固定窗口和缓存会改变计量或收费，输出 token、工具与基础设施还要另算。

业务 ROI 则需要更完整的账：

每任务期望成本
= 模型费用 + 工具及基础设施费用
+ 人工介入概率 × 单次介入成本
+ 失败损失的期望值
+ 分摊的建设与维护成本

为了展示敏感性，假设两个方案质量与失败损失相同，人工每次处理成本为 5 元：

这组数字不是实测，也不是产品定价。它说明：在这个假设下，增加 0.15 元机器费用，换取减少 1.25 元人工费用，才产生 1.10 元差额。真实项目必须验证介入率是否下降、处理质量是否相当，以及节省的时间能否转化为业务收益。

没有统一的“介入率低于 20% 就不值得做”阈值。低频但高价值任务、已高度自动化的海量任务，成本结构可能完全不同。

7. 多步成功率需要明确概率条件

如果三个必要步骤独立、每步成功率均为 90%，且没有恢复机制，全部成功的概率是：

0.9 × 0.9 × 0.9 = 0.729

独立性不成立时，应使用条件概率：

P(全部成功)
= P(S1) × P(S2 | S1) × P(S3 | S1, S2)

实际系统的错误常相关：错误订单号会影响后续每一步，错误知识也可能同时误导执行者与评估者。不能把单独测出的节点成功率直接相乘，声称得到端到端可靠性。

重试、核验与回退能改变路径及成功条件，但不会自动“打破概率规律”。核验器也有漏检与误报，必须通过端到端任务测量实际改善。

8. 业务执行需要稳定的操作身份

订单调查结束后，如果用户请求退款，系统可以让模型提取意图，再交给业务服务执行。关键不是禁止工具执行退款，而是不能绕过业务授权与状态约束。

下面是教学伪代码，展示职责顺序：

def submit_refund(intent, principal, request_id):
    order = orders.load_for_update(intent.order_id)
    require_can_refund(principal, order)
    amount = validate_refund_amount(intent.amount, order)
    require_approval_if_needed(principal, order, amount)

    operation = refunds.create_or_get(
        tenant_id=principal.tenant_id,
        request_id=request_id,
        order_id=order.id,
        amount=amount,
        currency=order.currency,
    )
    return refunds.submit_or_query(operation)

create_or_get 需要由数据库唯一约束或等价原子机制保证，并检查同一请求 ID 的参数一致性。不能用“先查是否存在，再执行”的两个普通操作代替。

请求 ID 由应用为同一业务操作生成并持久化；模型重新生成 tool call ID 时，仍要关联原操作。仅用“订单号+金额”也不够，因为同一订单可能存在合法的多次部分退款。授权判断应抛出明确错误，不能依赖可能被关闭的 Python assert。

支付接口超时后，先查已有操作的结果。稳定的幂等键、状态查询与对账共同保证恢复；一条审计日志本身不能防止重复退款。

9. 让自主性服务于交付

Agent 的能力不由组件数量、循环轮数或自主性标签决定。应先明确任务与授权范围，再用证据判断它能否更好地交付。

对于订单异常调查，一个有效的系统应能找到正确对象、补齐关键证据、保留未知状态，并把处理建议与实际操作分开。这些结果比“用了几个 Agent”更有意义。下一篇讨论如何把这些约束落实到运行时、工具契约和提示词组装。