面试官可能会问：“工具接口已经返回 200，为什么 Agent 最后还是做错了？”
这道题看起来像异常处理，实际是在检查你有没有把“成功”定义清楚。一次工具调用可以在协议上完全正常，真实函数也没有报错，但用户目标仍然没有完成。反过来，工具返回空结果不一定是系统故障，也可能是合法业务结果。若所有情况都压成一个 success: true，Agent 就无法判断下一步，监控也会把大量业务失败算成成功。
更稳的设计，是把成功拆成三层：调用协议成功、工具执行成功、业务目标成功。三层分别由不同证据判断，也对应不同责任人和失败出口。只有把它们分开，才能解释“接口没报错但答案错了”“工具查到了数据但任务没完成”以及“工具返回空为什么不该无限重试”。
先给出 30 秒回答
Agent 工具成功至少分三层。第一层是调用成功：tool call 能解析，工具存在，参数通过基础校验，结果按调用 ID 回传；第二层是执行成功：真实服务完成操作，返回结构符合契约，没有超时、权限或下游错误；第三层是业务成功：工具结果确实满足当前子目标，并推动用户任务达到可验收状态。HTTP 200 或函数不抛异常最多只能证明前两层的一部分，不能证明业务完成。工程上我会为三层分别记录状态和错误类型，让 Agent 根据空结果、缺信息、权限、暂时故障和业务拒绝走不同路径，并用端到端任务集验证最终成功。
这段话的重点是：系统“运行正常”和用户“事情办成”不是同一个指标。
三层成功对应三套证据，不能用一个布尔值替代。
第一层：调用协议成功
这一层回答的是“模型与宿主程序有没有完成一次合法握手”。
模型返回了 tool call，程序能读取工具名和参数，调用 ID 存在；工具名能在 Registry 中解析；参数 JSON 可以解析并通过 Schema 基础校验；程序将对应结果按 tool message 回灌。做到这些，只能说明协议链条没有断。
常见失败包括：模型没有返回工具调用；生成了不存在的工具名；参数不是合法 JSON；必填字段缺失；同一轮多个调用结果与 ID 对不上；程序只塞回结果，却没有保留原 assistant tool call。
协议失败时，真实工具通常还没有执行。处理方式可以是要求模型重新生成结构化参数、请求用户补充信息，或者在达到格式修复上限后停止。不能把格式错误直接传给任意执行函数，也不能用字符串拼接绕过 Schema。
这一层的监控应记录模型看到的工具集合、模型返回的工具名、参数解析状态、Schema 版本和调用 ID。它帮助你判断问题在提示、模型结构化输出还是应用协议。
第二层：工具执行成功
这一层回答“真实后端有没有完成它承诺的动作”。
宿主程序拿到合法调用后，还要做身份、权限和业务参数校验，再调用数据库、搜索服务、文件系统或业务 API。执行成功不是简单看有没有异常，而要按照工具契约解释返回。
例如搜索工具的契约可能是：在规定时间内返回一组格式正确的候选，允许结果为空。访问网页工具的契约可能是：读取允许访问的公开地址，返回与目标相关的正文或明确错误。写工具的契约还要包含幂等与确认结果。
常见执行失败包括：超时、下游限流、连接失败、返回结构变化、权限拒绝、资源不存在、结果过大和副作用状态不确定。不同错误是否可重试完全不同。
权限拒绝不是暂时故障，换个参数重试可能变成越权探测。资源不存在可能需要用户核对标识，而不是切换备用服务。超时有时可重试，但写操作超时后不知道下游是否已经成功，必须先按幂等键核对，不能直接再执行。
因此，工具层需要返回结构化 Observation，至少区分 ok、empty、invalid_request、forbidden、not_found、timeout、temporarily_unavailable 和 unknown。分类名称可以按项目调整，关键是让下一层知道事实，而不是只收到一段异常文本。
第三层：业务目标成功
这一层回答“工具结果有没有让当前任务真正向前推进”。
搜索接口正常返回十个链接，是工具成功，但如果用户要的是可核验结论，而这些链接都没有所需信息，研究子目标没有成功。订单查询返回一条记录，是工具成功，但记录不属于用户要找的时间范围，业务目标仍未完成。测试命令正常退出也不一定代表修复完成，可能根本没有覆盖目标问题。
业务成功必须从任务 State 和完成条件判断。当前子目标是什么，需要哪些证据，工具结果是否满足，是否仍有冲突或缺口，下一步是继续、换路、澄清还是结束。
模型可以参与语义判断，但不能单独决定所有业务成功。结构化事实应由代码检查：结果数量、必填字段、对象状态、权限、测试状态和审批状态。难以完全规则化的内容质量，可以由评审节点或模型给出有限决策，再由系统保存理由和证据。
最终任务成功又高于单个子目标。一个多步任务可能每个工具都执行成功，但整体顺序错误、关键步骤遗漏或最终答案没有使用 Observation。端到端验收必须以用户目标为准。
一个最容易误判的场景：空结果
空结果不天然等于失败。
搜索工具成功执行，但没有找到相关资料，这属于“执行成功、业务未满足”。程序不应把它当异常无限重试，也不应让模型编造一个答案。正确下一步可能是改写查询、换数据源、请求用户缩小范围，或明确当前没有证据。
数据库查询返回空，也可能是合法事实。需要先区分资源确实不存在、用户无权看到、筛选条件过严、数据同步延迟和参数错误。若工具把这些情况都返回空数组，Agent 无法正确决策。工具契约应尽可能提供可公开的原因状态，权限细节又不能泄露给无权用户。
空结果评估要看系统有没有产生新信息。如果只是连续用同一参数查询，任务没有进展；如果根据空结果调整了假设或向用户澄清，空结果仍然发挥了 Observation 的价值。
HTTP 200 为什么远远不够
HTTP 状态只能描述一次传输或服务请求的外层状态。很多业务 API 会在 200 响应体里返回业务错误，也有异步接口只表示“请求已接收”，真实任务稍后才完成。
工具适配器应把传输状态、服务错误和业务状态分开解析。比如：请求到达服务；服务接受任务并返回任务 ID；任务最终完成并产生结果。这三个阶段不能压成一次成功。
如果是长耗时工具，Agent 得到任务 ID 后应该进入等待、轮询或异步回调路径，而不是立刻生成“已经完成”。如果是最终一致的数据，结果暂时不可见也需要明确状态和重查条件。
同样，函数正常返回也不代表结果可用。返回字段缺失、版本不兼容、内容被截断或包含工具自己的错误提示，都需要适配器验证。
每一层只回答自己的问题，上一层成功才进入下一层判断。
怎样设计统一工具结果
一个有用的工具结果至少要同时服务 Agent 决策、业务代码和可观测系统。
{
"call_status": "valid",
"execution_status": "ok",
"business_status": "insufficient",
"data": [],
"error_type": null,
"retryable": false,
"evidence": [],
"next_hint": "refine_query"
}
这是教学示例，用于说明三层字段边界，不是生产接口。
call_status 说明协议和参数是否合格；execution_status 说明工具服务是否完成契约；business_status 说明当前子目标是否满足。retryable 由工具策略和错误类型决定，不能只由模型猜。next_hint 可以帮助 Agent 选择允许的下一步，但系统仍要限制候选动作。
成功结果也需要来源和版本。搜索结果要保留来源地址和抓取时间，数据库结果要有对象标识和数据版本，写操作要有业务凭证和幂等键。没有可核验凭证，最终层很难判断结果是否可以作为任务证据。
结果内容要控制大小。完整网页、日志或文件放工件存储，Observation 只放与当前目标相关的摘要、字段和引用。否则一次执行“成功”会把上下文撑大，后续模型反而无法使用结果。
谁来判断业务成功
代码规则
适合字段完整、状态枚举、权限、金额上限、测试退出码等确定条件。优点是稳定、可审计，缺点是难覆盖开放语义质量。
模型评审
适合判断资料是否回答了问题、报告是否覆盖关键维度等语义任务。要给它明确 Rubric、证据和有限输出，不让它自由说“很好”。
外部验证器
例如单元测试、SQL 校验、Schema 验证、引用检查器。它们提供独立于生成模型的信号，通常比让模型自评更可靠。
人工确认
适合高风险、不可逆或价值判断明显的动作。人工看到的内容必须与真正执行的动作绑定，确认后仍做权限和状态校验。
真实系统常把四种方式组合起来。代码先检查硬条件，外部验证器提供事实，模型判断开放质量，高风险结果交给人工。不要让同一个模型既执行、又定义标准、又给自己通过。
错误该归到哪一层
错误归因决定修复方向。
模型总是选择不存在的工具，优先检查可见工具、名称、描述和结构化输出，这是调用层问题。工具选择正确但持续超时，检查下游服务、超时和限流，是执行层问题。工具稳定返回，但结果不能解决用户目标，检查工具能力边界、任务拆解、规划和完成条件，是业务层问题。
如果最终答案没有引用已经返回的事实，工具和业务判定都可能正常，问题出在结果整合节点。它说明端到端成功不能由工具层代替。
一次 Trace 应保留三层状态和首次失败位置。后续重试成功时，也不要覆盖第一次失败，否则无法统计真实稳定性和恢复行为。
工具成功和步骤成功还要再区分
一个计划步骤可能需要多个工具共同完成。比如“找到资料并核验结论”先用 Search 找线索，再用 Visit 读正文，还可能用计算工具处理数字。三个工具各自成功，不代表步骤已经完成，因为来源可能相互冲突，或者仍缺少用户要求的时间范围。
因此，工具结果写入 Observation 后，应由步骤级验证器判断当前计划项是否满足。步骤状态可以是待执行、进行中、已满足、信息不足、被阻断和失败。只有步骤验证通过，Planner 才把它标记为完成并推进下一项。
这个边界能防止一种常见问题：Executor 看到工具返回就把计划项勾选完成，Finalizer 最后才发现关键证据没有拿到。将验证前移到步骤边界，错误可以在影响后续计划前暴露。
步骤成功也不等于整个任务成功。最终任务还要检查所有必要步骤、跨步骤一致性、输出格式和用户约束。三层工具成功解决调用诊断，步骤与任务成功解决多步编排验收，两套层级不能混成同一个 done。
工具契约怎样防止“假成功”
工具契约不应只描述输入字段，还要定义什么结果算执行成功。搜索工具返回空列表是否合法；访问工具拿到登录页而不是正文算不算成功；代码执行工具进程退出但测试没有运行算不算成功；这些都要写清。
可以为每个工具准备输出 Schema 和语义断言。输出 Schema 检查字段、类型和版本，语义断言检查关键内容是否存在。例如访问工具至少返回最终 URL、内容类型、抽取状态和正文摘要；若拿到验证码页，就应返回受阻，而不是把一段 HTML 当作成功正文。
契约还要定义数据新鲜度和完整性。缓存命中可以是执行成功，但若用户明确问最新信息，过期缓存不能满足业务层。分页接口只返回第一页时，工具应明确是否还有下一页，不能让上层误以为数据完整。
发布工具新版本前，使用固定样本跑契约测试。包括正常、空结果、权限、超时、格式变化和大结果。若执行器改了返回字段而适配器没更新，契约测试应在进入 Agent 之前就失败。
怎样处理部分成功
多来源任务经常出现部分成功：三个数据源中两个正常，一个暂时不可用；报告大部分问题有证据，少数问题没有。把部分成功压成完全失败会丢掉已有价值，压成完全成功又会掩盖缺口。
Observation 可以记录已完成项、缺失项、受阻原因和是否允许继续。Planner 据此决定调用备用工具、返回部分结果、请求用户选择，或等待关键依赖恢复。最终答案必须把缺口明确告诉用户，不能用已经成功的部分遮住未验证内容。
是否接受部分成功属于业务规则。只读研究任务往往可以在标注限制后交付；高风险审批或必须完整的数据同步通常不能。这个标准应在任务定义阶段写清，不能等执行失败后让模型临场决定。
状态码和自然语言都不能单独承担判定
只看状态码会忽略语义，只看模型对结果的自然语言解释又不稳定。更可靠的办法是分层组合：适配器把传输和服务状态转换成结构化结果；业务代码检查确定字段；模型只判断开放语义；最终节点把这些证据汇总。
例如工具返回“请求处理成功”，适配器仍要解析真实状态字段；模型说“结果足够”，验证器仍要检查必要来源是否存在；代码认为字段齐全，模型还可以指出内容与用户问题无关。每一层只做擅长的判断，并把理由留在 Trace 中。
这也能减少提示词依赖。若所有成功规则都写在系统 Prompt 里，模型版本或上下文变化会让判定漂移。确定性规则进入代码和契约，Prompt 只保留语义标准和表达要求。
同样叫失败，格式、执行、业务和最终整合需要完全不同的修复。
怎样设计三层指标
调用层可以观察工具调用决策、工具名解析、参数结构与调用结果关联。执行层可以观察工具可用、超时、返回契约、权限和错误类别。业务层可以观察子目标是否满足、是否产生新证据、人工是否接管以及最终任务是否通过。
这些指标不能混成一个“工具成功率”。假如调用与执行都很高，业务完成很低，说明工具能力、规划或完成条件有问题；如果业务样本只统计工具有结果的任务，又会掩盖空结果和无工具场景。
指标分母也要定义。执行成功率的分母应是通过调用与权限校验、真正进入执行的请求；业务完成率的分母应是对应任务样本，而不是返回非空数据的调用。所有数字必须从真实日志和评估集计算，不能在简历或文章里预填理想值。
怎样构造评估集
至少准备六类任务。
第一类是正常成功：协议、执行和业务都成功。第二类是协议失败：工具不存在、参数缺失、格式错误。第三类是执行失败：超时、限流、返回结构变化。第四类是执行成功但业务不足：空结果、结果不相关、证据不完整。第五类是权限与副作用：语义匹配但不能执行。第六类是最终整合失败：工具给出正确事实，模型却忽略或篡改。
每条样本标注三层期望状态、允许下一步和不可接受行为。例如空结果允许换查询或明确无证据，不允许编造；权限拒绝允许转人工，不允许连续重试；写操作状态不确定时允许核对，不允许再次提交。
评估时先看三层状态是否判断正确，再看最终任务。只用最终答案评分，很难定位失败；只用工具是否报错，又会把“执行成功但没办成事”当作优秀样本。
一套合格评估要覆盖协议、执行、业务目标和最终答案四个位置。
面试官会怎样连续追问
追问一：工具返回空数组算成功吗
执行层可能成功，业务层未必成功。要根据工具契约判断空是否正常，再根据子目标决定换查询、澄清、降级或明确无证据，不能统一当异常重试。
追问二：HTTP 200 为什么不能表示成功
它通常只说明请求传输成功。响应体可能是业务拒绝，异步任务可能只是已接收，返回字段也可能不符合契约。还要解析执行和业务状态。
追问三：业务成功由模型判断靠谱吗
开放语义可以让模型按 Rubric 提供判断，但硬条件由代码和外部验证器负责。模型决策要输出证据与有限状态，高风险任务需要人工。
追问四：重试成功后，第一次失败还算失败吗
要同时记录初次执行与最终恢复结果。覆盖失败会掩盖工具稳定性，忽略最终恢复又看不到系统韧性。
追问五：工具成功但最终答案错，责任在哪
先确认工具结果是否正确、是否满足业务子目标，再检查结果是否被正确回灌和整合。可能是规划、完成条件、上下文或最终生成节点的问题，不能一律归因工具。
追问六：为什么不只看端到端完成率
端到端是最终目标，但单一总分无法定位回归来源。三层指标用于诊断，端到端用于验收，两者缺一不可。
工具调用成功，到底怎样讲才完整
我会把 Agent 工具成功拆成三层。第一层是调用成功，模型返回的 tool call 能解析，工具存在，参数通过基础校验，结果和调用 ID 正确关联；第二层是执行成功，后端完成权限与业务校验，真实服务按契约返回，没有超时、结构错误或副作用不确定；第三层是业务成功，工具结果确实满足当前子目标，并让整体任务向完成推进。HTTP 200 或函数不抛异常最多证明执行链的一部分。工具结果会返回分层状态、错误类型、是否可重试和证据，空结果、权限、超时、业务拒绝走不同路径。评估也分别看调用、执行、业务和最终整合，保存首次失败与恢复 Trace。这样接口正常但事情没办成时，可以定位是协议、工具、规划还是答案整合问题。
别把 HTTP 200 当成功：核对三层证据
- 是否把调用、执行和业务成功分成独立字段与指标。
- 空结果、资源不存在、权限和超时是否能被区分。
- 业务完成条件是否来自真实任务，而不是模型一句“完成”。
- 写操作状态不确定时是否先核对幂等状态。
- Trace 是否保留首次失败、重试与最终恢复结果。
- 评估集是否覆盖工具正确但最终答案错误的样本。
工具不报错，只能说明系统没有在那个位置停下。用户目标是否真正完成，需要另一套证据。把“成功”拆开，是 Agent 从能跑通走向可诊断、可验收的第一步。