Agent-Reach：从意图路由到工具编排，提升AI Agent触达率的工程实践

1. 这个项目到底在解决什么问题

Agent-Reach 这个名字，我第一次看到的时候琢磨了一会儿。Agent 好理解，就是现在满屏都是的 AI 智能体；Reach 这个词才是关键——它强调的不是“能力上限”，而是“到底能触达多远”。这两年 AI Agent 的项目刷了一波又一波，朋友圈里全是精心设计的 Demo：能点外卖了、能订机票了、能替你开会了。但你真把其中任何一个扔到真实工作流里跑一个月，多半就露馅了——要么任务覆盖率不到三成，要么稍微有点歧义就罢工，要么干脆在某个角落里无限循环。问题不在模型智商，而在“够不着”：够不着用户真实的需求，够不着散落在各个系统里的工具，够不着复杂场景下那个需要临时决策的瞬间。

Agent-Reach 给我的感觉，不是一个具体的聊天机器人或者自动化脚本，而是一套方法论加工程实现：怎么衡量一个 Agent 是不是真的“触达”了目标场景，怎么通过架构设计把触达率做实，而不是停留在“能聊、能答”的肤浅层面。它适合谁看？两类人。一类是正在把大模型接进业务系统的开发者，你缺的不是模型 API，而是怎么设计工具编排、意图路由、记忆回退这些关键环节的工程经验。另一类是产品和技术负责人，你被各种 Agent 的 Demo 迷惑过，想找一个客观的评估维度来判断“这东西到底能不能用”。这篇文章我就按照 Agent-Reach 的思路，拆开讲讲“触达”这件事背后的技术解剖、实操落地和踩坑记录。

2. 整体设计与核心思路拆解

2.1 为什么触达比能力更重要

先说个扎心的现状。现在市面上的 Agent 框架，底层能力堆积非常夸张：上下文窗口动辄百万 token，插件市场几百个，模型推理能力卷到了天花板。但你去看实际使用数据，绝大多数 Agent 的死法不是“不够聪明”，而是“够不着需求”。

举个例子。我自己之前做过一个给运营团队用的问答助手，模型选的是当时最强的那一档，知识库也接了一大堆。结果上线第一周，用户反馈最多的一句话是：“我问‘帮我查一下上周华东区的转化率，跟环比比较一下’，它回了一堆大道理，就是不给我数字。” 模型当然知道转化率是什么，但它不知道去哪查、调哪个接口、维度怎么对齐。这就是典型的能力溢出了，但触达不到位。

Agent-Reach 的核心设计哲学，是把“触达”作为一个可量化的第一性指标。什么叫触达？拆开就是三个层次：意图触达（用户真正想干什么，Agent 是否准确识别）、工具触达（识别之后，能不能在正确的时间调用正确的工具拿到正确的数据）、价值触达（拿到数据之后，给用户的回答或动作是否解决了问题，而不是丢过来一堆通稿式输出）。这三层但凡断一环，用户体感就是“这 Agent 好蠢”。

所以 Agent-Reach 在架构上做的第一件事，不是继续往模型里塞知识，而是给 Agent 装上一套“体位感知系统”——让它清楚自己是站在哪个场景里、手里有什么牌、面对的是谁、目标是什么。这个思路跟人很像：一个人再聪明，到了一个陌生环境、手上什么工具都没有，也干不了活。Agent 也一样，先解决“身体坐标”，再谈“脑力发挥”。

2.2 从“单点能力”到“系统工程”的转变

接触 Agent-Reach 的过程中，我最大的感受是它把 Agent 开发从“Prompt 调优大战”拉回到了“系统工程”。传统做 Agent 的思路是写一大堆 Prompt、精心设计 ReAct 循环，然后祈祷模型给力。Agent-Reach 不是这么玩的，它更像是在搭一个生产线：需求进来，先分流到不同的工位，每个工位有明确的输入输出标准，遇到处理不了的情况要有明确的反馈路径，而不是让模型在原地打转。

强调一点，这里不是说要自己从零搭框架。Agent-Reach 是可以叠加在现有 Agent 框架之上的。你完全可以用 LangGraph 也好、Dify 也好、Coze 的 API 也好，只要这些框架允许你做自定义模块，Agent-Reach 的思路就能嵌进去。

我实际落地的时候，把架构分成了五个核心模块，画出来看其实不复杂，但每个模块都有讲究：

• 意图路由器：负责判断请求该走工具调用、知识库检索还是纯模型对话，并且给出置信度
• 工具编排层：管理所有真实可调用的 API 和数据源，包含参数映射和异常回退
• 记忆管理层：区分会话级的短期记忆和用户画像级的长期记忆，控制上下文膨胀
• 执行沙箱：负责跑多步工具的缓冲区域，带超时控制和循环检测
• 触达评测器：就是一套针对“触达率”的指标采集系统，任何一次任务结束，都会生成一份触达报告

这套架构的逻辑在于：把原本藏在模型黑盒里的“决策过程”显式地切成了几段，每一段都有明确的接管策略。模型负责它擅长的部分——语言理解、逻辑推理，工程系统负责模型不擅长的部分——可靠调用、状态管理、失败兜底。这就是 Agent-Reach 系统工程化思路的核心，不神化模型，也不把工程搞成铁板一块。

3. 核心细节解析与实操要点

3.1 意图路由：别让 Agent 像个无头苍蝇

先看 Agent 运行的第一道关卡：用户问题的理解与分流。2019 年左右做对话机器人，意图识别用的是意图分类模型加槽位填充，吭哧吭哧训练半年，中文效果还很一般。现在的 LLM 直接就能做意图识别，但直接让 LLM 自由发挥也有问题：它经常会自作聪明，用户问 A，它判断成 B，或者干脆不在你要的分类体系里。

Agent-Reach 在意图路由上的做法我总结下来就是一句话：给模型选择题而不是填空题。不要靠模型自己的话生成，靠模型在预设的分类树上做判断。我实际构建时先建立了一张意图分类表，大概长这样：

意图路由模块的工作机制是这样的：先由一层轻量级分类器或者带严格格式输出的 LLM 调用，基于这张表输出一个 JSON，包含意图ID和置信度分数。注意这里的关键技术点是置信度阈值的设定。我踩过的坑是：一开始把阈值定在 0.6，结果一堆模棱两可的请求全被分到“未知类”转人工了，人工那边压力骤增。后来调整到 0.4，但误判率又开始上升，用户问的是天气，Agent 去调了工单接口，还一本正经地说“你的订单未找到”。

最终我采用了双阈值策略：置信度大于 0.65 直接执行；0.4 到 0.65 之间走“澄清策略”，就是模型先生成一个澄清问题反问用户；低于 0.4 直接转人工。这样一来，既不因为过度谨慎让用户觉得“这 AI 怎么老反问我”，也不因为过度自信而胡乱调用工具。这套策略在 1200 条真实用户日志上回测，意图误判率从最初的 22% 降到了 6% 左右。

还有个小技巧：意图路由的输出一定要做成“可回退”的。也就是说，即便路由器判定了意图，在执行过程中如果发现工具调用返回的结果和意图完全对不上，还允许执行层发起一次意图重判，而不是将错就错。这个回退机制在真实场景里非常重要，尤其是用户表达习惯千奇百怪的时候。

3.2 工具编排：把“有的选”变成“选得对”

意图定了，接下来就是工具编排。Agent-Reach 的工具层设计有一个容易忽略但极其重要的原则：工具数量要克制，工具描述要精准。市面上不少 Agent 框架主打“接入几百个工具”，听起来很唬人，但实际用起来模型根本不知道什么时候该用哪个。这就像给了你一个工具箱，但里面几百把稀奇古怪的工具堆在一块儿，你找一把螺丝刀都得翻半天。

我自己做 Agent-Reach 落地的实践准则：工具总数控制在 20 个以内，每个工具的描述控制在三句话以内，第一句说“此工具做什么”，第二句说“在什么情况下使用”，第三句说“需要什么参数”。比如：

工具名: query_es_data 描述: 查询 Elasticsearch 中的业务指标数据 适用: 当用户询问具体的数字指标如转化率、订单量、销售额时使用 参数: index_name, start_time, end_time, aggregation_field

这一点看着好像稀松平常，但真到实际操作里，很多团队把工具描述写得像技术架构文档，模型读了半天也学不会，这是工程问题，不用归罪于模型能力。我建议所有工具描述都按照“场景触发条件 + 输入输出格式”两个维度去写，让模型像查表一样配对。

另一个关键点是参数映射。用户说“上个月的华东区销售数据”，工具要的可能是region=huadong、date_range=2025-01-01，这中间涉及到自然语言到结构化参数的转换。我一开始让模型直接生成工具调用参数，结果 JSON 格式时不时出错，日期格式五花八门。后来加了一个参数规范层，模型先输出标准化语义（如“上月、华东区”），再用规则映射到具体 API 参数。这个折衷方案极大提升了工具调用的成功率。

工具编排层还需要设计清晰的错误返回协议。每类错误落实成一个错误码：

• missing_param: 缺参数，触发澄清
• api_timeout: 后端接口超时，触发重试
• no_permission: 无权访问，触发提示与转人工
• empty_result: 查询结果为空，触发兜底话术，不硬编

这里我想重点强调一下常用的“工具调用重试”策略：不要一次性把全套重试逻辑塞进 Prompt 里，模型会混乱。正确做法是在代码层面完成重试，LLM 只负责发起调用和接收结果。比如 API 超时了，代码自动重试两次，每次间隔 500 毫秒，三次都不行再把错误返回给模型处理。这样做既让模型不用分心去考虑“怎么重试”，也让运行过程更可控，方便记录这次任务到底是“工具真失败了”还是“模型没理解参数”。

3.3 记忆管理：别让 Agent 失忆，也别让上下文爆炸

记忆这块是 Agent-Reach 里非常容易翻车又特别值得扣细节的部分。我见过大量 Agent 项目，要么完全不设记忆，用户提到两轮之前说过的偏好，模型一脸茫然；要么把什么历史都往上下文里怼，结果上下文越来越长，模型开始胡言乱语，还多收了不少 token 费。

Agent-Reach 对记忆的管理策略，我在实际项目中总结出一个“两级五段”的记忆模型：

• 第一级：会话短期记忆。缓存当前会话最近 20 轮的关键信息，存成摘要向量 + 原文摘要双备份。原文摘要用于在必要时回溯细节，向量用于快速判断“用户说的内容我是不是见过的”。
• 第二级：用户长期画像。用户偏好、业务属性、历史操作习惯，存在独立的存储里，例如 MySQL 或者 Redis，每次对话开始时按需拉取，而不是全文塞给模型。
• 第三段：业务快照。Agent 执行完一个重要操作后，把结果快照下来，比如单据编号、金额、时间，用于后续追问时快速调取。
• 第四段：操作日志。所有工具调用、条件分支、异常情况，落日志，便于排查和评测。
• 第五段：禁止记忆。明文标记一些不适合写入记忆的敏感信息，防止隐私数据长期驻留上下文。

这套机制的好处是：会话窗口里只保留当前任务必需的 10 到 15 条消息，其余都外置。模型每次要获取记忆，通过工具调用去查询，而不是在上下文里满满当当装一堆历史。这样既保住了触达的延续性（用户说“我上回让你查的那单怎么样了”，Agent 能通过记忆查到具体单号），也把上下文长度压在一个可控范围内，大幅降低了因上下文过长导致的指令遵从度下降。

有个特别常见的翻车案例：用户让 Agent 帮忙查三个不同维度的数据，查完之后说“第三个再帮我细看一下”。如果会话里没有结构化的记忆，模型很可能理解为“把三个都再看一遍”，或者干脆忘了第三个是什么。有了业务快照机制，Agent 会记录“第三个 = 华东区商品类目销售对比”，然后反问“你指的是华东区商品类目那个吗？”——用户体感会好非常多，尤其是复用率高的高频工具场景。

3.4 安全护栏与权限控制：触达的另一面墙

很多做 Agent 项目的人容易把护栏问题放到最后再想，但 Agent-Reach 的做法是护栏前置，因为“触达”不仅要触达得远，还要触达得稳、触达得不出事。尤其是操作类能力（发起流程、修改订单、发送消息），一旦权限控制不严，Agent 的破坏力远大于它的价值。

我对 Agent-Reach 护栏层的核心理解是：操作越重，确认越繁琐。查数据不需要二次确认，但写操作至少要有三步确认：先说将要做什么，让用户确认后再发起预执行，最后展示结果并明确标记已完成。这里可以设置一个“危险动作清单”，凡是落在这个清单里的操作（发送对外消息、删除数据、修改订单状态、涉及金额变动）,全部需要在代码层面强制二次确认。

另外，所有工具调用，都要做参数白名单校验。什么意思呢？就是模型生成参数后，先经过代码规则过滤，看数值范围是否合理、字段是否有权限、是不是符合预期状态。我踩过一次坑：模型在调用日期筛选时，居然生成了“2024-02-31”这种不存在的日期，下游系统直接报错，用户看到了底层异常信息，体验极差。后来我在校验层加了一条规则：所有日期参数必须能被 Python 的datetime.strptime成功解析，否则一律拦截。诸如此类的小校验逻辑，不加你根本不知道模型有多能“作妖”。

权限上，我的实践是“场景化授权”而不是“全局授权”。每个 Agent 场景对应一组受限的 API 集合和操作范围。比如“数据查询 Agent”只能访问只读接口，“订单操作 Agent”只能访问订单域的写接口，且必须获得用户明确授权。这套思路和零信任模型有点像：即使 Agent 内部出了幻觉，它调不动没有授权的接口，破坏面就控制住了。

4. 实操过程：从零到一搭一个带 Agent-Reach 能力的问答助手

4.1 技术选型与基础环境准备

理论说了一堆，实际动手才是真章。我自己搭 Agent-Reach 风格应用的时候，选了这套比较省心又灵活的组合：

• 语言框架：Python 3.10+，FastAPI 作为服务对外接口
• Agent 核心：LangGraph，因为它的 StateGraph 模型适合做显式的状态流转，配合工具节点、控制节点，落地 Agent-Reach 这套“路线图式”的流程非常顺手
• 模型接入：走标准 OpenAI 兼容接口，主模型我用的 DeepSeek-V3 和 Qwen-Max 轮换，意图路由这种轻任务用 Qwen-Turbo，便宜也够用
• 向量库：本地起了一个 chroma，用于用户长期记忆和知识库检索
• 业务数据源：一个模拟的 MySQL 数据库，里面建了订单表、转化率汇总表、用户表，用于演示查数功能

有人可能问：为什么不直接用现成的 Dify 之类的拖拽平台？说实话，Agent-Reach 这种偏“触达评测”的思路，拖拽平台在自定义评测逻辑和控制粒度上不太够用。自己用代码搭一遍流程，后面调阈值、加回退逻辑、埋评测指标都会顺手得多。如果你只是验证 idea，Dify 也行，但我建议至少在本地先把控制逻辑跑通。

4.2 构建意图路由和工具节点的完整链路

搭建的核心代码结构，我拆成三个部分来看。

第一部分是意图路由节点。我这里没有写特别复杂的模型逻辑，而是通过强制 JSON 输出来实现：

from pydantic import BaseModel class IntentResult(BaseModel): intent_id: str confidence: float clarified_question: str = "" def route_intent(user_input: str, history_summary: str) -> IntentResult: prompt = f"""你是意图路由器。请将用户请求分类为以下类别之一： query_data, query_status, start_process, modify_process, chitchat, help, unknown。 规则： 1. 如果用户请求与之前的对话有关（如'那笔订单''刚才说的那个'），请参考历史摘要。 2. 只输出JSON，格式为：{"intent_id": "...", "confidence": 0.0-1.0, "clarified_question": "如果置信度低于0.65，请写一个澄清问题，否则留空"} 3. 操作类意图（start_process, modify_process）默认置信度需乘以0.9，防止误判。 历史摘要：{history_summary} 用户输入：{user_input} """ resp = llm.chat(prompt, model="qwen-turbo", response_format="json") result = IntentResult.model_validate_json(resp) if result.confidence < 0.4: result.intent_id = "unknown" return result

这一小段代码看起来简单，但是有四个隐藏细节：一是response_format="json"保证模型输出能被解析，避免字符串解析地狱；二是历史摘要压缩到不到 200 字，避免信息过载；三是操作类意图的概率乘了一个 0.9 的折扣系数，这是从实际误判数据里挖出来的经验；四是置信度低于 0.4 直接强转 unknown，不会因为模型“强行猜一个”导致后续步骤做错。

第二部分的工具节点，核心是标准化的调用注册和执行：

TOOLS = {} def register_tool(name, description, schema, handler): TOOLS[name] = {"description": description, "schema": schema, "handler": handler} def call_tool(name, params): if name not in TOOLS: return {"error": "unknown_tool"} try: return {"result": TOOLS[name]["handler"](**params)} except Exception as e: return {"error": "tool_error", "detail": str(e)}

执行调用工具的时候，Agent 是在一个“执行沙箱”里面操作的。实际操作中我会加两样东西：一是超时控制器，单次工具调用超过 15 秒直接中断并返回超时错误码；二是循环检测器，比如同样一个工具，连续调了三次还是同一个错误码，就不再重试，直接跳到人工兜底话术。

第三部分是把这些节点织成可运行的 Agent：

from langgraph.graph import StateGraph, END class AgentState(TypedDict): user_input: str intent: dict tool_calls: list response: str needs_clarification: bool builder = StateGraph(AgentState) builder.add_node("intent_router", route_intent_node) builder.add_node("memory_loader", load_user_memory_node) builder.add_node("tool_executor", tool_exec_node) builder.add_node("answer_generator", generate_answer_node) builder.add_node("clarifier", ask_clarify_node) builder.set_entry_point("intent_router") builder.add_edge("intent_router", "memory_loader") # 关键分支：置信度低走澄清，否则走记忆加载再到工具执行 builder.add_conditional_edges("memory_loader", lambda state: "clarifier" if state["intent"]["confidence"] < 0.45 else "tool_executor") builder.add_edge("tool_executor", "answer_generator") builder.add_edge("clarifier", "answer_generator") builder.add_edge("answer_generator", END)

这里条件边的触发阈值和意图路由里的阈值是故意分开的。路由节点那里只负责初判，到了执行链路里会再判断一次，形成双重保险。实际效果是：置信度低的请求不会直接进工具执行，而是先跟用户确认，确认结果会回到意图路由节点重新跑一轮，更新后的状态再继续执行。

4.3 触达评测指标怎么采集与解读

Agent-Reach 很有价值的一点，是它所倡导的“一切用数据说话”。你上线 Agent 后不能只靠“感觉还行”，得有实时指标。我在项目里构建了一套触达评测规则，每次任务结束都会自动生成一份触达报告，核心指标有这些：

这些指标不是拍脑袋定的，是从 2000 条日志里算出来的当前基线。如果你善用评测数据，很快就能发现系统最薄弱的环节具体在哪：是意图识别的边界模糊，还是工具层的老接口不稳定，还是回答阶段的上下文缺失。一旦定位到具体环节，用样例数据去专项调优，比盲目调 Prompt 高效十倍。

我特别说明一下“一次性解决率”这个指标。很多做 Agent 的同学容易忽略它，但这个是用户体感最直接的一个。如果用户问你一个问题，你回答完之后他说“不对，我要的不是这个”又补充了一句，那就算没解决。这个指标一旦异常，基本说明意图澄清或者上下文管理环节有问题。我调的思路是：每次回答末尾加一个“确认钩子”——“这是你想了解的吗？如果不是，告诉我你需要的具体方向”——通过用户的反馈把这轮数据打上标签。有了标签，后续就能精准找出那些理解偏差的样本，用来继续优化路由节点和工具选择的配合。

4.4 推理成本与性能平衡实操记录

Agent-Reach 落地过程中，还有一个绕不开的现实问题：成本和延迟。你不可能每个任务都让最强模型从头到尾跑一遍，那样延迟受不了，钱也受不了。我的策略是三层模型部署方案：

• 轻量模型（如 qwen-turbo 级别）：承担意图路由、历史摘要、工具结果整理，速度快，成本低
• 主力模型（如 deepseek-v3 级别）：负责真实回答生成、复杂多步推理、需要综合判断的场景
• 重型模型（如最强闭源模型）：仅在极端复杂任务上启用，比如用户涉及多个条件交叉的数查或者多轮操作调度

这里要强调一个筋斗：成本优化不能牺牲触达率。如果轻量模型在意图路由上误判率明显高于主力模型，就要权衡是否值得省这点钱。我自己实测下来，用 qwen-turbo 做意图路由，在“查询类”意图上准确率和 main 模型差距很小，但在“操作类”意图上差得比较多，因为操作类意图的表达往往更隐蔽、更口语化，需要更强的推理能力。所以我最后的方案是：默认用轻量模型路由，但特定类型的表达（比如用户话里带“帮我处理”“取消一下”等触发词）自动升级到主力模型重判。这种“降级路由 + 触发升级”的策略，已经在多个项目里帮我平衡了效果和成本。

5. 常见问题与排查技巧实录

5.1 意图误判的样本分析与修复

整一整实际的坑。做 Agent-Reach 这套东西，最常见的翻车场景就是意图误判。我自己遇到的典型案例：用户说“这个月是不是快放假了”，Agent 把意图识别成了“查询请假流程”，然后开始介绍怎么提交请假申请。用户一脸懵，其实就是想聊天而已。这种误判不是模型笨，而是意图分类表里把“放假”和“请假”语义靠得太近了。

排查方法也很直白：把所有误判的日志样本拎出来，字段分析，一句话总结“模型将 A 识别成了 B”。然后统计误判高频对，把它们写进意图路由规则里。比如"放假" in input and "流程" not in input -> 判定为 chitchat。这类硬规则一旦积累到一定量，路由准确率会上一个台阶。

还有个思路是建立“相似意图混淆矩阵”，每两周分析一次。矩阵里行是真实意图，列是模型判定意图，对角线越高越好，非对角线上的高值点就是你要处理的重灾区。我会挑混淆矩阵中 Top 3 的误判组合，挨个看原始对话，再针对性地加规则或改提示词。这个方法比盲目调参准得多。

5.2 工具调用失败的四种典型场景

第二个高频问题，工具调用失败。表面上错误五花八门，但归纳一下无非这四种：

1. 参数格式错误（模型生成了非法 JSON、日期不存在等），解法是靠参数校验层硬拦，模型输出后先过规则校验再调接口
2. 接口本身超时（第三方不稳定），解法是幂等重试加熔断，同一个接口失败三次，直接切备用通道或者转人工
3. 工具选择错误（该调 A 工具却选了 B），解法是优化工具描述，让描述里的触发条件更贴合用户口语表达
4. 依赖状态过期（比如用户请求里带的上下文是两天前的，此时某些业务数据已经失效），解法是执行前加上一次状态检查，确认涉及的单据、流程仍是可操作状态

构建时建议给每个工具加一层“重试策略”配置：

tool_config = { "name": "query_dimension_data", "retry": {"max_retries": 2, "backoff_ms": 500}, "fallback_tool": "query_summary_from_cache", "timeout_sec": 10 }

有个血泪教训是：不要只依赖 LLM 自行修复工具调用错误。模型在工具调用失败时，常会“自圆其说”编造一个结果。你没看错，是真的会编。比如调接口失败后，模型居然回答说“根据系统数据，华东区订单量是 10086 单”。所以代码层面一定要有校验机制：如果工具返回错误码，宁可让 Agent 说“我暂时查不到，请稍后重试”，也绝不能放模型自由发挥去编结果。

5.3 上下文膨胀与“失忆”的平衡术

第三个问题，上下文膨胀。用户对话超过十轮，模型开始前面的忘了，后面的乱了。要么是记不住用户之前提及的条件，要么是答非所问。这个问题几乎每个做 Agent 的人都会遇到，Agent-Reach 应对策略前面已经写过了：外置记忆、摘要替代原文、工具调用拉取上下文。这里给几组建议参数：

• 会话窗口保留消息条数：不超过 12 条
• 单条消息截断上限：2000 字符
• 摘要触发的轮次：第 6 轮开始生成当前摘要
• 长期画像的拉取间隔：每次会话开始时拉取一次，中间按需刷新

我实测这么设置以后，带 30 轮以上长对话的任务，最终回答准确率能稳定在 85% 以上，而之前把全部上下文怼进去时只有 65% 上下。原因并不玄学，模型注意力机制在面对超长上下文时确实会发生“迷失现象”，尤其是不相关内容夹杂在关键信息之间时尤为明显。自己做 Agent 时，必须接受一个现实：模型不是把所有历史都塞给它就能表现得更好，“该记的记、该忘的忘”才是工程的正解。

5.4 常见问题速查表：能救命的排查清单

把高频问题整理成一张表，给照着排查的同行一个速查工具：

这张表是我自己调试时的习惯整理，每加一条都是真实踩过的坑。如果你跑到类似的场景，建议直接带这张表进调试现场，比自己瞎想快得多。

6. 一些实际体验中的细节心得

Agent-Reach 这套思路我用下来，最大的收获倒不是某一个模块做得多巧妙，而是它给整个 Agent 工程提供了一根主线——“触达”这个指标把所有零散的工作串到了一起。以前做 Agent 项目，目标经常含糊，一会儿说“要更像人”，一会儿说“要更准”，这些问题没有一个能直接指导你改哪行代码。Agent-Reach 不一样，它的目标很干脆：用户的问题进来了，你有没有在合理轮数内、用合理的方式，让他得到他要的东西。触达不到，说什么都是白搭。

按照我的个人经验，上线新 Agent 的第一周最好每天都盯触达指标曲线，特别是“转人工率”和“一次性解决率”。这两个指标对调整意图路由阈值和工具描述，给出的信号又快又准。前一个爆了说明你理解用户需求的覆盖面有问题，后一个爆了说明你的解决方案和用户预期有落差。根据这两个信号做针对性迭代，一版一版地改，系统会肉眼可见地变好。

最后分享一个小技巧：在 Agent 的响应入口加一个不显眼的反馈收集逻辑，比如用户对结果点“没用”或说“不是这个”，自动把整轮对话采样存起来。攒够几百条，你会惊喜地发现，一个高质量的场景评测集就攒出来了，而且全部来自真实用户，比任何从网上抄来的测试集都有说服力。有了这份数据集，无论是做离线评测还是后续微调，你的 Agent 都已经跑在绝大多数人前面了。