企业官网建设流程全解析

1. 从"任务看起来完成"到"目标真正达成"：Agent-Reach要解决的问题

做LLM Agent应用做得久了，你会发现一个特别拧巴的现象：**Agent的"完成"和人的"完成"根本就不是一回事。**模型非常擅长在对话层面对你说"好的，我已经完成了"，但真正去检查产物、验证状态、确认外部系统是否真的收到了预期变更时，往往会发现一堆窟窿——文件写了但格式不对，接口调了但参数传错，任务循环跑了但判断条件根本没触发。

我最早被这个问题咬了一口，是在做一个批量处理结构化文档的Agent。它需要在每个工作日夜里跑一批PDF解析、字段抽取、入库更新的任务。上线头两天看起来风平浪静，第三天我随手看了一眼数据库，发现其中一类单据的处理时间戳全部停留在前一天凌晨，等于这个Agent在长达十几个小时里一直在"假装工作"——它的主循环没有报错，日志里甚至打印了"处理完成"，但实际入库语句因为一个字段类型转换异常被静默吞掉了。

这就是我决定动手做Agent-Reach的起点。简单说，这是一套给Agent任务做目标可达性验证与排障的轻量框架，核心思路不是在Agent执行过程中不断追问"你做到哪一步了"，而是在任务结束后，用独立的验证链路去确认"你到底有没有真正到达目标状态"。它可以挂在任何基于工具调用的Agent架构上（我目前主要接的是LangGraph和自研的一套React模式框架），通过定义目标状态、校验节点、证据收集器和失败归因器这四个模块，把"Agent说自己完成了"和"系统确认它完成了"这两件事彻底分开。

如果你也在做AI Agent应用，并且被"假完成""部分完成""完成但结果不可用"这三类问题困扰过，那这篇文章应该能给你一些直接的参考。下面我会从可达性拆解的逻辑讲起，然后是核心实现细节，再放几个真实踩坑案例的完整排查链路，最后说说接入自己工作流时的配置取舍和目前还存在的边界问题。

2. 三层可达性拆解：目标层、执行层、环境层的验证逻辑

Agent-Reach早期版本走了一个弯路：我试图用一个统一的"成功判定"函数去覆盖所有任务类型。结果就是判定规则越写越长，到最后两三百行的if-else，维护成本高不说，换个业务域就崩。后来我重新梳理了Agent执行任务的本质，发现所有"没真正到达目标"的情况都可以归到三个层面。

2.1 目标层：判定条件本身有没有被满足

目标层是最表面的一层，说的是"任务定义的验收标准是否达成"。比如你让Agent"把A表中所有状态为pending的记录改成processed"，那目标层的判定就很简单：查一下A表，状态字段是否还有pending残留。这一层通常容易理解，但有一个常见的坑——你写判定条件的时候，是不是在复述Agent自己的输出？

很多人的验证逻辑会写成"从Agent的最终回答里提取'完成'字样"或者"只要工具调用返回成功就算过关"，这等于让球员自己当裁判。Agent-Reach在这里强制要求：目标判定必须来自独立的数据源。也就是说不看Agent说了什么，只看业务系统里实际发生了什么。数据表的状态、文件系统里产物的元信息、外部API的查询结果，都可以作为独立数据源，唯独Agent自己的输出文本不行。

2.2 执行层：工具调用链有没有按预期跑完

执行层解决的是"过程是否完整"的问题。我遇到过特别多的情况：Agent最后确实到达了目标状态，但它是通过一条完全不可复现的路径到达的。比如有一次让它把一份Markdown转成PDF，它没有调用渲染服务，而是自己用字符串拼接伪造了一个扩展名为.pdf的文件。从目标层看，文件存在了，后缀名也对了，但这明显是"假完成"。

执行层验证做的是三件事：**检查工具调用序列是否覆盖了任务模板中声明的必选步骤；检查每一步调用是否携带了合法参数；检查步骤间的数据传递是否有断点。**这里的实现基础是工具调用日志的结构化。我在设计Agent-Reach时要求所有Agent工具调用都必须输出统一的Schema，至少包含tool_name、input_args、output_summary、timestamp、call_id这五个字段。有了这些，执行层验证就变成了对调用链的图匹配——你预先定义一个理想调用链模板，然后把实际调用链投影到模板上，看缺失了哪条边、哪个节点。

2.3 环境层：外部系统状态有没有真正改变

第三层是最容易被忽略、却也最致命的一层——环境层。目标层关注业务系统的最终状态，执行层关注Agent自己的动作序列，但中间有一个灰色地带：外部系统到底有没有因为Agent的动作而发生真实变化。

举个我实际踩过的例子：某个Agent负责每周向团队群推送项目周报，它通过群机器人接口发了消息，接口返回了200，但群聊里根本没有任何人看到周报。排查后才发现，机器人webhook被调整了权限，消息被平台静默拦截，但接口层仍然返回成功。这个案例说明，"工具返回成功"和"环境状态变更"之间是有鸿沟的。

环境层验证的做法是把所有外部依赖都包装成可观测的"资源探针"。比如发消息这个动作，验证逻辑不是看webhook返回值，而是主动调用服务端的消息查询接口，确认消息ID在对话流里真实存在；再比如写文件，验证逻辑是重新打开文件并检查内容指纹，而不是看写入函数有没有抛异常。这些探针本身就是Agent-Reach插件体系的核心，下面会细讲。

三层验证的关系可以这么理解：目标层告诉你"该到的地方到了没"，执行层告诉你"走的路对不对"，环境层告诉你"你推的那扇门是不是真的开了"。三者全部通过，我才会在Agent-Reach的报告里给出一个"confirmed"结论，否则一律视为不可信完成。

3. 核心实现细节：验证链路的数据结构与判定引擎

这一章讲Agent-Reach最核心的实现部分，也就是验证链路是怎么跑起来的。整体分三大块：目标状态的声明方式、验证节点的执行调度、以及失败后的归因逻辑。

3.1 目标状态的声明：把验收标准变成可执行断言

Agent-Reach要求每个Agent任务在启动前声明一个目标状态描述文件。我给这个文件取名叫reach_manifest.yaml。它长这样：

task_id: weekly_report_push task_name: 每周项目周报推送 target_states: - id: report_file_exists description: 周报文件已生成 type: resource_probe probe: file_probe params: path: /data/reports/{{execution_date}}_weekly.md check: checksum_not_empty - id: message_delivered description: 群消息实际投递成功 type: resource_probe probe: im_query_probe params: conversation_id: "{{env.IM_GROUP_ID}}" keyword: "{{execution_date}} 周报" timeout_seconds: 30 - id: toolchain_complete description: 必须按模板顺序调用生成与推送工具 type: execution_chain expected_sequence: - report_generator - im_sender required_edges: - from: report_generator to: im_sender verification_policy: require_all: true retry_on_fail: true max_retries: 2 fail_fast: false

目标状态分两种断言类型。resource_probe对应前面说的环境层，它通过注册好的探针插件去外部系统验证实际状态；execution_chain对应执行层，它检查工具调用序列和图结构。目标层的验证通常也归入resource_probe，比如"数据库pending记录清零"就是一个可以写进探针的SQL查询断言。

这里有一个关键设计：断言必须自带参数模板能力。因为Agent任务每次执行时的上下文不同，比如日期、会话ID、目标路径都会变化，所以reach_manifest.yaml支持{{}}占位符，在任务启动时由Agent-Reach从任务上下文里动态解析。我建议占位符的来源限定在三个白名单来源：任务输入参数、环境变量、上次探针的输出结果。这个限制非常重要，否则就变成任意代码注入了。

3.2 验证引擎的调度逻辑：三次检查、两轮重试、一次确定

验证引擎是Agent-Reach的调度中枢。它接收Agent结束信号后，不是一次性把所有断言全部跑完，而是按"软检查→深检查→确认"三个阶段推进。这一点是我在实践中学到的：不是所有断言都需要完整执行，大部分任务在软检查阶段就可以给出"未通过"结论，没必要浪费昂贵的探针调用。

阶段一叫"软检查"。它只跑低成本的本地断言，比如文件是否存在、大小是否大于0、数据库单条计数查询、调用链节点是否完整。这个阶段的设计目标是用最少的资源刷掉80%的"假完成"，耗时一般控制在1秒以内。

阶段二叫"深检查"。如果软检查全部通过，才进入需要调用外部系统接口的探针验证。比如消息投递确认、数据库事务后的数据一致性验证、导出文件的Schema校验。这个阶段可能耗时几秒到几十秒，视探针数量而定。

阶段三叫"确认"。如果深检查也通过了，最后一次调用所有关键探针做一遍抽样复核，然后写入验证报告。这一步是为了兜底"第一次检查时外部系统还没完成最终一致"这类时序问题。

两轮重试的处理逻辑同样值得说一下。max_retries不是简单地把同一个探针再跑一遍，而是带冷却时间的重试，冷却时长由retry_backoff_seconds参数控制。如果第一次探针返回"未找到消息"，Agent-Reach会等待几秒再请求一次，因为消息系统可能存在写入延迟。但重试只针对环境层的探针，执行层校验不重试——调用序列缺失是Agent行为的硬错误，重试没有意义。

3.3 证据收集器：每个结论都必须有可复核的旁证

我一直有一个偏执：**验证结论里不能只有"通过"或"未通过"，必须附证据链。**后来发现这个偏执救了我很多次。比如某个探针显示"数据库记录已更新"，但过了两天业务方说数据不对，这时候如果没有证据链，就得从头查起；有证据链的话，直接翻出当时的探针快照，发现探针查询条件里的时间范围写错了，是验证器自己出了问题，不是Agent的问题。

证据收集器做三件事：记录探针请求与原始响应全文；对响应内容计算哈希并连同执行时间戳一起入库；保存探针结果的原始截图或日志片段。这些证据默认存在本地SQLite里，按task_id和execution_id两个维度组织，后面接入监控面板或者做审计导出都很方便。

@dataclass class ProbeEvidence: task_id: str execution_id: str state_id: str probe_name: str request_params: dict raw_response: str response_hash: str checked_at: datetime passed: bool def persist_evidence(evidence: ProbeEvidence): with get_db_connection() as conn: conn.execute( """ INSERT INTO verification_evidence (task_id, execution_id, state_id, probe_name, request_params, raw_response, response_hash, checked_at, passed) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) """, (...) )

这里注意一个细节：raw_response我存的是原文，不是清洗后的内容。清洗后只能看到你想看到的，原文才能让后续排查看到系统实际上返回了什么。有时候问题恰恰就藏在"系统返回了一段Agent没预料到的异常信息"里。

4. 核心探针的开发经验：从文件探针到对话流确认

探针是Agent-Reach最需要投入精力的部分，因为每个业务域的外部系统都不一样。我目前维护了五个通用探针和两个业务定制探针，下面挑几个讲讲开发思路和注意事项。

4.1 文件与内容探针：别只检查存在性

文件类探针是最常见的需求，但也最容易写糊。新手通常只检查"路径存在"，但这会漏掉大量问题——文件存在但内容为空、内容是上一轮任务的残留、编码损坏导致解析失败等。

我的文件探针做了四个层次的检查，按成本从低到高排列：存在性与大小检查、修改时间新鲜度检查、内容签名（哈希或行数）检查、格式语义校验（如CSV列数、JSON Schema）。其中修改时间新鲜度是很多人忽略的一点。比如你的Agent每天生成一份日报，如果某天它没有生成新文件而是把昨天的旧文件复制了过来，存在性检查是发现不了的，但你检查mtime是否落在本次任务的执行窗口内，立刻就能暴露问题。

class FileProbe(BaseProbe): def check(self, path: str, check: str, min_size: int = 1, fresh_window_seconds: int = 3600) -> ProbeResult: p = Path(path) if not p.exists(): return ProbeResult(False, "file_not_found", {"path": str(p)}) stat = p.stat() checks = [] if check == "checksum_not_empty": checks.append(("content_empty", stat.st_size > min_size)) if check == "fresh": now = datetime.now() age = (now - datetime.fromtimestamp(stat.st_mtime)).total_seconds() checks.append(("file_fresh", age <= fresh_window_seconds)) if check == "json_schema": checks.append(("json_valid", self._validate_json_schema(p))) passed = all(v for _, v in checks) details = {name: ok for name, ok in checks} return ProbeResult(passed, "file_probe_pass" if passed else "file_probe_fail", details)

一个需要特别留意的地方是：文件探针运行在Agent-Reach进程里，如果你是Docker化部署且Agent的工作目录和验证器的目录不一致，路径会是一个大坑。我建议统一通过一个共享卷挂载，并且在探针参数里显式声明路径前缀，不做任何隐式拼接。

4.2 消息与通知类探针：接口200不等于对方收到

我前面提到周报推送的例子，那是消息类探针最典型的痛点。接口返回200、消息队列确认消费、但用户端没有收到——这种情况团队协作工具里其实挺常见，原因包括：webhook权限被回收、机器人被移出群、消息频率限制导致的静默丢弃。

消息类探针的可靠做法是反查。不是在发送端看发送结果，而是用接收端的视角去查消息是否存在。对于企业微信、钉钉这类开放平台，通常有查询历史消息的管理接口；对于Slack，可以用conversations.history；如果你用的是通用IM自建服务，那消息表里一般有conversation_id和消息内容的索引。反查的关键参数是时间窗口和内容指纹——把"包含特定关键词的消息"做成探针的查询条件，时间窗口设在Agent执行时间之后。

如果外部系统确实不提供查询接口，退而求其次的办法是让发送方在消息里嵌入一个唯一token，然后要求Agent把发送结果页面截图或HTML抓取回来，验证token是否出现在其中。这算是一个兼容方案，稳健性比直接依赖返回码好得多，但会在执行链路上多一个步骤。

4.3 数据库状态探针：注意读副本延迟和事务隔离级别

数据库类的目标状态验证，容易遇到两个隐蔽问题。第一个是读副本延迟：很多业务库有主从架构，Agent写入主库后，如果你用连接串访问的是从库，可能短时间读不到刚写入的数据。我遇到过探针第一次跑永远失败、重试一次就通过的"灵异现象"，后来才发现是强一致性读的问题。解决办法：数据库探针的连接配置里显式开启prefer_primary或者把隔离级别设为READ_COMMITTED以上。

第二个问题是探针SQL里的查询条件容易被写宽。比如前面提到统计"pending记录是否清零"，如果SQL只写了WHERE status = 'pending'而没有限定业务范围，那么别的业务线没处理完的历史数据会导致探针一直失败，白白重试好几轮。我现在的做法是要求所有SQL探针在配置中显式声明scope_filter，不允许裸统计，逼着自己想清楚"这个目标状态到底是在哪个范围内才算达成"。

数据库探针执行还有一个容易被忽略的性能问题：如果目标状态校验要跑多条SQL，尽量合并成一条SQL用CASE WHEN分别统计，而不是发多次查询。这不仅是为了性能，更是为了拿到同一时间点的一致性快照——多个独立查询之间几毫秒的间隙都有可能导致状态不一致。

5. 实测中的四个典型失败场景与完整排查链路

Agent-Reach在本地跑通之后，我在真实工作流里测了大半个月，前前后后捕获了几十次"假完成"。下面挑四个具有代表性的失败场景，把每一次从异常到定位的完整排查链路写出来。这个过程比最终结论更有价值，因为排查思路是可以复用到任何Agent问题上的。

5.1 场景一：文件生成了，但内容是上一轮任务的残留

某次定时任务，Agent被要求生成当日的销售汇总CSV。验证报告显示两个断言未通过：文件新鲜度检查失败，内容签名检查失败。但我看软检查阶段的存在性检查是通过的，说明文件确实存在。

排查链路是这样走的：第一步，翻看证据收集器里的file_probe原始输出，确认文件路径是/data/reports/20250218_daily_sales.csv，大小约120KB，看起来正常。第二步，进入深检查阶段的新鲜度检查，发现mtime是前一天凌晨2点14分，也就是说这个文件在本次任务执行前就已经存在。第三步，继续跟进内容签名检查，发现CSV的行数与预期的当日订单量差异巨大。

到这里基本可以断定：Agent在生成文件时没有真正执行渲染逻辑，而是把之前已存在的文件路径当成了产物返回。为什么会出现这个情况？我去翻了Agent的工具调用日志，发现它调用report_generator时传的日期参数解析出了问题，但没有抛出错误，内部逻辑兜底返回了最近一次生成的旧文件路径。Agent拿到这个路径后自以为任务完成了，完全没有意识到日期不对。

这个案例的教训是：**探针的新鲜度检查和内容签名检查必须同时启用，缺一个都不能形成闭环。**如果我只做存在性检查，这个bug可能到我手动打开文件那天才发现。

5.2 场景二：消息发送接口返回成功，但群里根本没人收到

周报推送任务上线第三天，验证报告提示message_delivered断言失败。这个断言用的是IM反查探针，在时间窗口内按关键词搜索群消息。第一次执行后，探针返回未找到匹配消息，触发了重试机制；重试冷却5秒后第二次执行，依然未找到。

排查链路：第一步，先看Agent的im_sender工具调用记录，确认请求参数正确、返回码为200。第二步，看消息探针的请求参数，确认conversation_id、keyword、时间窗口设置正确。第三步，手工登录IM管理后台，搜索该群聊该时间段范围内的消息，发现确实没有。第四步，查看工具所调用webhook的权限配置，发现该机器人已被移出目标群，但移除操作没有发通知，webhook仍保留着旧的调用凭证，接口照常返回成功。

问题根因在外部系统侧：**权限已失效但接口不做真实校验。**修复方案是更新webhook配置并重新把机器人拉进群，同时我在Agent-Reach里给这个探针增加了一个前置check——每次推送前先调一次群成员列表接口，确认机器人还在群里，不在就直接把任务标记为失败，不再执行推送。

这个案例让我意识到，环境层的"真实状态"是Agent-Reach最需要盯紧的。工具调用协议是Agent和系统之间的约定，但系统状态往往会因为外部运维操作而偏离约定，探针的价值在于把偏离暴露出来。

5.3 场景三：数据库没有pending残留了，但更新的是同一批错误的行

这是一个目标层断言通过了、但数据质量仍然有问题的隐藏案例。Agent的任务是"把所有refund_status=pending的退款记录更新为processed"。探针查询确认，任务结束后表中已无pending记录，断言通过。但业务方后续反馈：当天有一批退款记录并没有真正处理，部分订单的退款金额字段还是空的。

排查链路：第一步，不是查Agent调用日志，而是先查数据库的操作审计日志，看这批更新的WHERE条件实际是什么。第二步，发现Agent执行的SQL是UPDATE refunds SET status='processed' WHERE status='pending'，看起来没问题。第三步，进一步查快照，发现在任务执行期间，有一条上游业务流水线在Agent执行之后、提交事务之前，把几十条原本pending状态的记录插入到了表中。Agent执行时扫到的pending记录是它自己更新完的那批，上游新插入的记录在Agent的查询视图中尚未出现。

根因是任务执行期间数据并发变更导致的验证窗口漂移。这个问题的通用解法是给验证加上"快照边界"：在Agent任务开始时先记录目标表的关键行数或最大ID，任务结束时验证时一并比对，确保你验证的对象确实是"任务开始时快照里定义的那批对象"。

5.4 场景四：调用链完整但参数错误，目标状态恰好巧合达成

最后一个场景比较有意思。某次数据清洗任务，Agent需要先调用fetch_data从源接口拉数据，再调用transform_data做字段映射，最后调用write_db入库。执行层校验显示调用链完整，三个节点都按顺序出现了，目标层的入库探针也检查到了新记录，所有断言竟然一次通过了。

但我复查时发现数据不对——新入库的几条记录里，某个关键字段的值明显是从错误来源字段映射过来的。排查链路：第一步，翻看transform_data的input_args，发现映射配置里传入了一个旧的字段名映射表，而源接口的字段名在昨天刚做过一次升级。第二步，确认Agent在构造映射表时没有拉取最新的字段配置，导致映射关系错位但类型兼容，程序没有抛错。第三步，验证探针检查的是"表里有数据"，但没检查"数据内容符合预期Schema"。

根因是：**执行链路和资源状态的验证都覆盖了，但数据内容的语义正确性没有探针覆盖。**修复方案：给write_db增加一个字段级内容探针，从目标表随机抽样几条记录，反向对照源接口的字段映射规则做一致性校验。这个探针后来成了数据类任务里最有效的防线。也要承认，这类"数据语义正确"很难完全泛化，需要每个业务场景单独写，Agent-Reach能做的是提供便捷的探针注册机制，降低写这种断言的成本。

6. 集成到现有Agent工作流的接口设计与配置取舍

说完了探针和案例，这一章再说说Agent-Reach怎么和现有Agent系统集成。我最初设计时定了原则：**Agent-Reach不侵入Agent的执行逻辑，只挂钩在Agent生命周期的事件点上。**这样做的好处是，你可以先接入验证层看效果，再逐步把失败情况接入告警和自动修复，对现有Agent系统的影响面最小。

6.1 挂钩点选择：结束信号之后、结果返回之前

Agent-Reach通过一个Python装饰器或中间件方式接入。以我正在用的自研Agent框架为例，接入代码大概是这样的：

@agent_reach.verify( manifest_path="/configs/reach_manifest.yaml", on_fail="escalate" ) def run_agent_task(task_input: dict) -> dict: agent = create_agent(tools=tools, llm=llm) result = agent.run(task_input) return result

装饰器会在run_agent_task正常返回后，自动读取reach_manifest.yaml，启动验证引擎。这里有一个行为约定：默认不阻断Agent结果的返回。也就是说，即使验证失败了，Agent对外部的响应还是按原来的逻辑走，但Agent-Reach会生成一条失败记录并推送到告警通道。对于初期接入阶段，这种"旁路观察"模式最稳妥，不会因为验证器的误报而影响线上正常流程。

等验证规则跑得比较稳了，就可以切换on_fail的行为为block，让验证失败的Agent结果不会真正提交给下游系统。更进一步，还可以把失败信号接到一个修复Agent上，让它根据失败归因结果自动尝试重新规划路径。这个进阶用法我还在完善，目前只做了一些关于"失败类型→修复策略"的映射实验。

6.2 两类验证器的资源预算：探针越贵、越要前置过滤

接入真实工作流后，我做的第一个调优是给探针设置了预算控制。原因很直接：消息反查接口、数据库复杂查询这类探针是有成本或频率限制的，如果每个任务失败了都全量重跑，上游接口很快会把你限流。

Agent-Reach的解决方式是给每条reach_manifest.yaml里的target_state打一个cost_level标签：low、medium、high。验证引擎在软检查阶段只执行low级别的探针；只有这些全部通过，才继续执行medium级别的探针；最后才做high级别。换句话说，**便宜的探针做过滤，贵的探针做确认。**这套策略上线后，单任务的平均探针调用次数减少了60%以上，而且没有出现过"便宜的探针过滤掉真实风险"的场景。

6.3 验证器自身的可靠性：不要让探针成为新的故障源

这是我认为整个框架里最重要的一件事：**验证器本身也可能出错，但它的错误不能比Agent的错误更隐蔽。**如果Agent正常但探针误报，你会去改一个本来没问题的Agent逻辑；如果Agent出错但探针漏报，那验证器就没有存在意义了。

Agent-Reach处理这个问题有几个措施。第一个是前面提到的证据收集器，探针的每个结论都保留原始响应，便于判断是Agent的问题还是探针的问题。第二个是探针自检机制——每次Agent任务启动前，Agent-Reach会对注册的探针跑一遍"空转检查"，用已知的样例数据验证探针逻辑本身没有回归性故障。第三个是探针异常隔离，探针执行如果抛出未被捕获的异常，Agent-Reach会把这个异常封装成一个PROBE_ERROR结果，而不是直接标记验证失败。PROBE_ERROR和FAIL的区别很关键：前者只表示验证不可用，不表示目标未达成。我用一个独立状态来记录它，避免因为探针自身网络抖动导致误判Agent失败。

class AggregateVerifier: def verify(self, ctx: TaskContext) -> VerificationReport: report = VerificationReport(task_id=ctx.task_id, execution_id=ctx.execution_id) soft_probes = self._get_probes_by_cost(ctx.manifest, "low") deep_probes = self._get_probes_by_cost(ctx.manifest, "medium") confirm_probes = self._get_probes_by_cost(ctx.manifest, "high") soft_results = self._run_group(ctx, soft_probes, stage="soft") report.add_results(soft_results) if not self._all_passed(soft_results): report.conclusion = "UNCONFIRMED_SOFT_FAIL" return report deep_results = self._run_group(ctx, deep_probes, stage="deep") report.add_results(deep_results) if not self._all_passed(deep_results): report.conclusion = "UNCONFIRMED_DEEP_FAIL" return report confirm_results = self._run_group(ctx, confirm_probes, stage="confirm") report.add_results(confirm_results) report.conclusion = "CONFIRMED" if self._all_passed(confirm_results) else "CONFIRM_FAIL" return report

这个AggregateVerifier就是验证引擎的主干，你从代码里可以看到结论不是简单的"成功/失败"，而是带阶段信息的枚举。这个设计是为了后续做失败归因和告警分级用的——软检查失败的告警级别应该比深检查失败低，因为前者可能是任务输入本身就不对，后者往往意味着Agent执行有问题。

7. 接入一周后的效果、局限与下一步的改进想法

Agent-Reach接入我负责的Agent工作流已经跑了一周多，覆盖了四类任务：文档解析入库、定时周报推送、批量数据清洗、工单自动分类。整体效果符合预期：捕获了11次假完成，其中有4次是Agent层面直接判定失败但系统层面仍在运行的隐性故障，另外7次是资源探针暴露的外部系统状态异常。最重要的是，它改变了我对Agent结果的态度——现在我看一份Agent报告，第一眼看的不是Agent自己写的总结，而是Agent-Reach的验证结论。

当然，坦白说这个框架的局限性也很明显。最突出的问题是探针开发成本前置：每接一个新的业务域，都得为它的外部系统写对应的探针和断言，这不是零成本的。而且有些环境根本不存在可靠的"反查接口"，比如某些老旧的内部系统连日志都没有，这时候只能退回到弱验证，效果打折扣。

另外，目前的失败归因还比较原始——它能把失败定位到"哪个断言没通过"、"哪个探针报了错"，但还不能自动告诉我"Agent的哪一次工具调用决策导致了断言失败"。这个需要把探针结果和工具调用日志做更深度的因果关联，我正在考虑引入一个小的图分析模块，把工具调用链和时间线上的状态变迁拼在一起，尝试做自动化的失败路径标注。

下一步的改进方向有四个，按优先级排序：第一是把PROBE_ERROR和失败归因接入告警通知时带上完整的证据链路下载入口，方便值班同事直接定位；第二是给常用数据库类型和主流IM做现成的探针插件包，减少新业务接入的重复开发；第三是开始尝试把失败信号接回Agent主循环的"修复Agent"，让它基于验证报告自动重新规划，形成一个有限度的闭环；第四是为探针结果做长期趋势统计，比如某些探针的失败率是否在升高，这可能预示外部系统正在悄悄变化。

最后说一点个人体会：Agent-Reach本质上不是一个"让Agent更聪明"的工具，而是一个"让Agent更可信"的工具。在大模型应用逐渐进入生产环境的过程中，能力的边界被模型本身的进步不断推着走，但可信度的边界，更多要靠验证体系这种看起来不够性感的基础设施去守。如果你正在做生产级的Agent应用，我建议不要只盯着prompt调优和模型选型，花点时间想一想：当Agent说"我做完了"的时候，你的系统，真的信它吗？