Agent说“已经完成”，不等于外部系统真的达到了目标状态。工具调用没有异常，也可能只是成功查询、提交了后台任务，或操作了错误对象。LangSmith新增的AI Search让开发者按行为描述寻找轨迹；对维护者更有用的问题是：找到可疑会话后，怎样把完成声明与实际证据对上。

下面的三态验收例子区分：已核实完成、已核实未完成、证据不足。它不代替行为模型，只把人工审读时容易混淆的判断拆开。Read in English。

这次新闻新增的是行为搜索

LangChain于2026年10月13日发布AI Search官方介绍，Developer Tech News在14日作了报道。它让用户用自然语言描述行为，先用结构化过滤缩小范围，再由决策模型检查轨迹是否匹配描述。

与“找到包含完成两个字的消息”相比，这类搜索试图判断一个关系：用户要求了什么，Agent做了什么，随后又怎样描述结果。关键词相同不代表行为相同；真正完成与只声称完成，可能出现在内容很相似的会话里。

因此，适合的使用方式是发现值得检查的样本，再进入证据核验与回归评测。不要把搜索结果直接当作事实裁决，也不要把没有搜到某种行为当成它一定没有发生。

先分清三种不同的“成功”

第一种是调用层成功：某次操作按接口语义正常结束。第二种是任务层成功：请求指定的目标状态已经实现。第三种只是语言层的成功声明：“已导出”“已保存”“已提交”。这三者可以同时发生，也可能彼此脱节。

OpenTelemetry错误记录规范围绕被观测操作的异常、错误返回与上下文判断失败。它不能自动替应用定义每个业务任务的最终后置条件。若一个接口成功接受异步请求，仍需由应用判断后续任务是否完成。

例如，虚构的导出任务返回了任务编号，说明请求被接收；它尚不能单独证明文件已经生成且内容正确。相反，一次工具失败后重试成功，也不能只凭中间那个错误就认定整个任务失败。审查必须看完整的、与当前目标相关的证据链。

把行为描述写成可复核的问题

“这个Agent不靠谱”太宽，难以得到一致的判断。可以改成：“会话中明确声称导出完成，但后续回读显示目标文件尚未生成。”这个描述包含声明、对象、时间关系与反证，审读者更容易知道需要查看哪些消息。

如果想找的是“操作了错误版本”，描述里就需要版本身份；如果想找“忽略了工具错误”，就要保证实际工具结果可见。将几个不同失败模式塞进一个句子，会让搜索结果难解释，也会使人工标注标准摇摆。

结构化条件适合收窄客观范围，例如同一部署版本、时间窗口或测试标签；自然语言部分专注行为。官方过滤文档也区分字段过滤和AI搜索，并说明AI搜索依赖轨迹包含的内容。字段信息没有进入轨迹时，不能指望模型从自然语言中补出它。

三态判断，比缺证据就判失败更稳妥

一项完成声明需要明确的后置条件。下面的教学例子约定：必须有一条与任务、目标对象匹配，且在动作后核实的回执，才能判断完成状态。它只是这个例子的验收契约，不是所有业务都必须只有一条回执。

若回执确认目标未完成，完成声明与证据矛盾；若没有回执，判断应停在“证据不足”。缺少证据可能是任务未做，也可能是采集或关联缺失。把它们都贴上“虚假完成”，会让排查结果混入并未证实的指控。

# Invented structured receipts; this is not an AI Search implementation.
request = {"task": "demo-1", "target": "report-v2"}

def assess(request, receipts):
    matching = [r for r in receipts
                if r.get("task") == request["task"]
                and r.get("target") == request["target"]
                and r.get("verified") is True
                and r.get("after_action") is True]
    if len(matching) != 1:
        return "unknown"
    complete = matching[0].get("complete")
    if complete is True:
        return "completed"
    if complete is False:
        return "not_completed"
    return "unknown"

def review_route(claims_done, state):
    if claims_done and state == "not_completed":
        return "contradiction"
    if claims_done and state == "unknown":
        return "needs_evidence"
    return "no_contradiction_established"

good = dict(task="demo-1", target="report-v2", verified=True,
            after_action=True, complete=True)
bad = dict(good, complete=False)
assert assess(request, [good]) == "completed"
assert assess(request, [bad]) == "not_completed"
assert assess(request, []) == "unknown"
assert assess(request, [dict(good, target="other-report")]) == "unknown"
assert assess(request, [dict(good, after_action=False)]) == "unknown"
assert assess(request, [good, bad]) == "unknown"
assert review_route(True, assess(request, [bad])) == "contradiction"
assert review_route(True, assess(request, [])) == "needs_evidence"
print("verified complete, verified incomplete, and missing evidence stay distinct")

代码已在本地执行，覆盖正常完成、确认未完成、缺失回执、错误目标、旧回执和多条冲突回执。它使用明确虚构的数据，不读取真实日志，不调用LangSmith，也没有测试AI Search的分类准确率。

真实系统需要根据业务扩展这个契约：多对象任务可能需要逐项回执，最终一致的状态可能需要等待，异步任务可能有独立生命周期。示例中多条回执返回未知，是为了要求明确解决冲突，不能直接照搬成所有生产任务的规则。

谁来写“已核实”，比布尔值本身更重要

示例中的verified=True不是证据本身，而是为了演示判断流程所作的输入约定。真实系统不能让Agent把自己写出的“已完成”转换成同一个标志，再用它证明自己。核实应来自可信的验收路径，例如读取实际目标状态，或运行针对交付物的检查。

验收条件也需要先定义。若任务是导出指定字段的数据，仅有文件存在不一定足够；还要核对任务要求的格式、版本或必要内容。检查项由业务需求决定，不应在看到结果后临时缩小成最容易通过的那一个。

记录中保留验收依据与产生它的步骤，才能让下一位维护者复查。若证据来源没有被核实，就继续保留未知；把一个字段命名成verified，并不会自动赋予它可信度。

长轨迹的截断，会改变模型看见的证据

官方介绍说明，AI Search使用整理后的trajectory，并为每条轨迹分配8K token预算，按优先级保留内容。关键工具结果可能未被保留，这限制了某些行为判断。这个数是公告中的产品处理预算，不是本文测得的模型容量。

想象一个虚构会话：Agent先说完成，工具稍后返回失败，再有回读确认目标未更新。若检查器只见到前一句，问题就变成了证据选择，而不只是模型推理能力。再强的判断模型，也不能可靠读取一段根本没有提供给它的结果。

所以复核时应回到原始轨迹，确认声明与工具结果之间是否存在关联、是否被截断、是否属于同一任务。若证据只显示请求已接收，就不要补写成任务完成；若原始采集本身缺失，也应把缺口记录下来。

搜索结果不能直接用来估计故障率

行为搜索适合发现案例，但返回的会话不是天然的随机样本。先筛选报错记录，再搜索完成声明矛盾，得到的是该筛选集合中的候选，不是所有线上请求的失败比例。

若需要评估检测效果，应准备独立人工审核样本，固定行为定义，分别查看命中样本中的误报和未命中样本中的漏报。没有审核未命中部分，就很难知道搜索遗漏了多少。本文不编造这类线上统计，也不把候选数量解释成准确率。

发现一个典型问题后，可将脱敏且有授权的样例加入回归集，验证后续修复是否改善同一失败模式。测试条件应包括任务对象和证据来源，避免只把“最后一句听起来更谨慎”当作问题修好了。

调试数据本身也需要边界

轨迹常包含输入、输出和工具参数。行为搜索发现泄露，不能替代采集之前的数据最小化。保留什么、谁可以访问、保存多久，应在接入前确定；不要为了方便调试就默认上传所有原始内容。

当前官方启用说明要求管理员明确授权相关数据处理，并说明美国处理及数据驻留影响。界面所在区域不能单独证明所有处理都在同一区域。本篇没有启用该功能、上传用户数据或改动任何账户设置。

本地实验优先使用虚构轨迹和无敏感内容的任务标识。若以后采用真实样例，先确认授权与脱敏，再把行为标签和必要证据留在评测记录中；没有必要的私人内容不应为了“让模型看懂”而额外收集。

让完成声明来自验收状态

更可靠的长期修复，是让Agent在声明完成之前获得可解释的目标状态。接口响应、动作结果与回读证据分别记录，并关联到同一个任务和对象。找不到这条链时，应如实报告当前阶段，而不是用一句“已完成”补齐。

任务涉及重试时，还要防止重复动作与旧结果混淆，可接着读Agent工具调用的幂等重试。幂等性帮助处理重复请求，验收状态帮助确认结果，行为搜索帮助发现遗漏；三者回答的是不同问题。

这条新闻的实用价值，是让难写成固定字段的失败行为更容易被发现。维护者仍需把候选变成证据，把证据变成明确的修复，再用同一契约复查，才能知道Agent实际完成了什么。

来源与验证范围

LangChain官方介绍，2026年10月13日；Developer Tech News报道，10月14日；LangSmith过滤与AI搜索文档；OpenTelemetry错误记录规范。Google News条目时间为UTC 10月14日09:14:17，早于本文计划时段。图形、验收契约和代码为原创教学示例。