当业务开始大规模搭建基于技能Skill-Based的 LLM 智能体时我一度以为只要把任务完成率、回答准确率、端到端时延管好就万事大吉。直到某个低峰时段云厂商账单中的 token 消耗和外部 API 调用次数突然翻了三倍我才意识到一个很容易被忽视的问题任务结果一直是正确的但执行路径早就“绕路”了而且大量不同任务正在汇聚到同一条高成本链路上。这篇文章将以“Convergent Detour Hijacking: Task-Preserving Resource Amplification in Skill-Based LLM Agents”为线索从命名拆解、典型成因、影响评估、可观测性建设、检测策略和工程防护几个方面展开。整个视角偏防御和可观测性适合已经在做 LLM Agent 落地、或者正在设计智能体监控体系的开发者。1. 背景与核心概念1.1 什么是基于技能的 LLM 智能体基于技能的 LLM 智能体Skill-Based LLM Agent是目前生产环境里比较常见的一种架构形态。它的核心思路是把大模型当作“规划器”把具体能力封装成“技能”或“工具”由大模型根据用户请求动态决定调用哪些技能、按什么顺序调用。一个典型的技能路由架构通常包含三个组件技能注册表维护技能名称、参数 Schema、复杂度等级、依赖关系。规划器根据用户请求生成执行计划决定技能序列。执行器按计划调用技能并把结果拼接回对话上下文。举个例子用户问“今天上海适合穿什么衣服”规划器可能会生成三步调用天气查询技能获取温度、湿度、风力。调用穿衣建议技能结合天气数据生成建议。使用输出格式化技能整理成一段自然语言回复。这种架构的优点是灵活、模块化也方便团队独立维护不同技能。但它也有个隐患规划器毕竟是一个概率模型它对“该用什么技能、按什么顺序用”的判断并不总是符合设计预期。一旦判断发生偏移任务结果可能仍然正确但内部执行路径已经变得低效甚至异常。1.2 一个容易被忽略的风险任务成功不等于执行健康在我最初的项目监控里关注的核心指标是任务完成率和可用性。理论上只要任务完成率稳定、用户没有投诉执行链路内部的小波动并不值得紧张。但某次版本发布后我发现了下面这些异常任务的最终答复没有明显变化用户反馈正常。按任务 ID 展开执行日志后发现很多任务的技能调用链从正常的 2 到 3 步变成了 8 到 10 步。明显不同的用户请求最终都汇聚到了同一个重型技能链路上。外部 API 的调用次数、token 消耗、执行耗时都出现倍数级增长。这种问题最隐蔽的地方在于从结果看任务成功从安全看没有越权从产品看用户无感。但是成本在持续膨胀下游系统的压力也在增加。如果多个智能体实例同时出现这种模式资源预算很容易被快速耗尽甚至拖垮依赖的外部服务。1.3 Convergent Detour Hijacking 是什么根据标题术语可以把这个概念拆成几个单词来理解Convergent汇聚的不同任务、不同输入最终走向相似或相同的非预期路径。Detour绕路执行路径偏离了设计时的标准路径。Hijacking劫持原本受控的执行流程被替换成了非预期流程。Task-Preserving任务保持最终仍然完成了原始任务没有暴露明显错误。Resource Amplification资源放大资源消耗被放大包括 token、外部 API 调用、执行时长、下游系统压力。合并来看它描述的是一种智能体异常行为模式在执行任务时不破坏任务结果但执行路径发生“绕路”并产生资源放大效应。作为一种研究型术语它的价值在于把一类模糊的“成本异常增长”问题抽象成一个可识别的模式方便我们做检测和防御。需要强调的是本文不讨论任何攻击利用细节而是从防御与可观测性角度分析如何发现这类异常、如何评估损失、如何在工程上做防护。2. 术语拆解从命名理解异常模式2.1 Task-Preserving为什么难以被识别Task-Preserving任务保持是这个模式最核心的伪装色。传统异常检测通常会以“任务是否失败”作为判据比如超时、报错、返回空结果。但任务保持型异常恰恰绕过了这个判据。举个例子一个设计为“两步完成”的文本摘要任务实际执行路径变成了这样提取关键词。调用外部搜索引擎做背景补充。对搜索结果做深度排序。再次提取关键词。重新生成摘要。最终返回的摘要质量可能还不错用户没有感知。但从成本角度这已经多消耗了两次外部 API 调用以及大量上下文 token。所以检测这类异常不能只盯“成功/失败”还需要对“执行路径是否符合预期”做建模。换句话说任务成功是一个最低标准不是健康标准。2.2 Resource Amplification后果量化Resource Amplification资源放大描述了这类异常的实际危害。它不是一个抽象概念而是可以被量化的指标集合。在一个基于技能的智能体里资源消耗通常体现在以下几个维度资源维度示例指标放大特征Token 消耗输入 token、输出 token、上下文累积 token技能调用次数增加上下文被反复塞入中间结果外部 API 调用搜索次数、数据库查询次数、第三方接口次数同一输入被重复转发给下游服务执行时长端到端时延、技能平均耗时路径变长导致端到端时间线性增加下游系统压力QPS、连接数、慢查询数多实例同时放大时压力会汇聚到共享服务成本按量计费账单以上指标最终表现为费用上涨在生产环境里建议把这些指标按任务维度聚合并计算“单任务资源消耗中位数”和“P95 消耗”。一旦两个数值出现显著偏离就说明存在异常放大。2.3 Convergent从随机异常到系统性异常模型偶尔出现一次路径偏移可能是随机性导致的可以容忍。但 Convergent汇聚性意味着大量任务最终走到了相同或者高度相似的高成本路径这就不再是随机噪声而是系统性异常。汇聚特征非常关键因为它是我们可以用来做自动检测的突破口。随机绕路的路径指纹通常是分散的而汇聚式绕路会产生一个高频路径指纹。之前我排查时使用了一个简单思路把每个任务执行的技能名称序列作为“路径指纹”然后按天统计指纹频率。正常情况下路径指纹应该比较分散且集中在设计好的标准路径附近。如果某条非标路径的指纹频率突然排进前几名就需要重点检查。2.4 Detour Hijacking执行路径被替换的判定Detour 描述的是“偏离”Hijacking 描述的是“受控流程被替换”。在基于技能的智能体里标准路径通常由产品设计和技能注册表决定而实际执行路径由模型规划器动态生成。两者之间的差异就是我们需要关注的绕路空间。判断一个执行路径是否被“劫持”需要先建立基准。最简单的方式是维护一份“标准路径表”把高频任务的理想技能序列固化下来。然后在运行时对比实际路径如果实际路径与标准路径一致视为正常。如果实际路径更长但技能序列是标准路径的超集视为“路径延长”。如果实际路径包含了与任务无关的技能视为“路径异常”。这种对比不需要复杂的数学模型基于规则和统计就能覆盖大部分生产场景。3. 典型成因与触发场景3.1 技能选择歧义技能选择歧义是最常见的成因。当多个技能名称、描述或参数在语义上接近时规划器可能选择一个更“重”的技能来处理简单任务。比如技能注册表里同时有summarize轻量摘要基于当前上下文生成简短总结。deep_rerank_summarize深度摘要先检索外部资料、再排序、再总结。如果两个技能的描述写得不够清晰模型很可能在简单摘要任务上选择深度摘要技能。这就是一个最基础的 Detour虽然没有破坏任务但资源消耗被放大了。3.2 链式调用中的级联放大技能本身还可能调用其他子技能。当规划器选择了一个带有子调用能力的技能时资源放大效应会沿着调用链级联传播。举个例子extract_keywords - web_search - fetch_page - parse_content - deep_rerank - summarize一个简单的“提取关键词”任务可能最终触发一串重型子技能。每个子技能都有独立的 token 成本和外部 API 开销。当这种链路被多个任务复用后资源消耗就会急剧膨胀。3.3 外部接口重试与分页放大还有一类放大不是模型主动绕路而是外部接口逻辑导致的。比如一个技能内部对下游 API 做了重试和分页拉取一旦没有设置合理的重试上限或每页数量就可能产生大量重复请求。这种情况下规划器本身没有异常但技能内部实现放大了资源消耗。因此在分析 Convergent Detour Hijacking 时需要同时关注两个层面规划器层面的路径异常。技能实现层面的资源消耗异常。3.4 多轮上下文累积导致的重复执行在多轮对话场景中上下文里可能残留历史技能执行结果。有些规划器会把历史技能输出当作本轮输入的一部分导致同一个技能在同一轮里被重复执行。比如用户第二轮追问“再总结一下刚才那篇文章”模型可能重新执行“解析文章”“向量化”“生成摘要”整条链路而不是复用第一轮的中间结果。这种重复执行同样会造成资源放大而且会随着对话轮数增加变得越来越严重。4. 影响评估为什么“任务保持型”问题更危险传统系统故障往往表现为可用性下降容易触发告警。但任务保持型异常会长时间潜伏因为它既不失败也不影响最终结果质量只会安静地消耗资源。从影响面来看可以按以下维度评估影响维度具体表现严重程度判断成本损失token 和外部 API 费用上涨账单环比突增时高度可疑性能退化端到端时延上升路径变长导致 P95 时延恶化下游依赖第三方服务 QPS 激增可能触发限流影响其他业务可扩展性单任务成本过高导致规模化受阻单位任务毛利为负时无法扩大规模系统稳定性长链路增加失败点单个子技能超时会拖垮整个任务在评估优先级时我比较看重的指标是“资源消耗放大率”也就是实际资源消耗与标准路径资源消耗的比值。资源消耗放大率 实际单任务资源消耗 / 标准路径单任务资源消耗当这个比值持续大于 2 时基本可以认定为显著异常需要定位并处理。5. 可观测性建设记录执行路径和资源消耗要发现 Convergent Detour Hijacking前提是系统具备足够的可观测性。否则我们只能看到成本账单却看不到任务内部发生了什么。5.1 技能调用链记录器最简单的方式是给每个技能调用加上链路追踪。下面是一个基于 Python 的示例思路它会把技能调用的父子关系、耗时、token 预估和外部 API 次数记录下来。# 文件路径observability/trace_recorder.py import time import uuid from dataclasses import dataclass, field from typing import Optional dataclass class SkillCallRecord: call_id: str task_id: str skill_name: str start_time: float end_time: Optional[float] None parent_call_id: Optional[str] None estimated_tokens: int 0 external_api_calls: int 0 status: str running metadata: dict field(default_factorydict) class SkillTraceRecorder: def __init__(self): self._records {} self._call_stack [] def start_call(self, task_id: str, skill_name: str, metadata: dict None) - str: call_id uuid.uuid4().hex[:12] parent self._call_stack[-1] if self._call_stack else None record SkillCallRecord( call_idcall_id, task_idtask_id, skill_nameskill_name, start_timetime.time(), parent_call_idparent, metadatametadata or {} ) self._records[call_id] record self._call_stack.append(call_id) return call_id def end_call(self, call_id: str, tokens: int, external_calls: int, status: str completed): record self._records.get(call_id) if record: record.end_time time.time() record.estimated_tokens tokens record.external_api_calls external_calls record.status status if self._call_stack: self._call_stack.pop() def get_path(self, call_id: str): path [] current self._records.get(call_id) while current: path.append(current.skill_name) current self._records.get(current.parent_call_id) if current.parent_call_id else None return list(reversed(path))这段代码的核心是维护一个调用栈。每个技能开始调用时记录它是哪个父技能的子树结束时把 token 和外部 API 次数回填。最终get_path可以还原出完整的技能调用链。5.2 日志结构建议采集到调用链之后建议把关键信息写入结构化日志。下面是一份 JSON 日志示例{ timestamp: 2025-01-01T12:00:00.000Z, task_id: task_123456, call_id: a1b2c3d4e5f6, parent_call_id: null, skill_name: parse_sql, status: completed, estimated_tokens: 850, external_api_calls: 0, duration_ms: 320 }有了结构化日志后续就可以用日志分析工具或写脚本扫描异常路径。5.3 关键监控指标建议为每个任务聚合以下指标技能数量单个任务实际调用的技能个数。路径深度调用链最大深度。外部 API 调用次数出网请求总次数。Token 消耗估算输入输出 token 总量。端到端时延任务启动到结束的耗时。这些指标按小时聚合并与历史基线对比是初步发现资源放大的基础。6. 检测策略识别汇聚式绕路6.1 标准路径库检测绕路的前提是知道“标准路径”是什么。建议为高频任务建立标准路径库示例格式如下# 文件路径detection/standard_routes.py STANDARD_ROUTES { user_summary: [extract_keywords, summarize], data_query: [parse_sql, query_db, format_result], daily_report: [read_project_data, summarize, format_report], }标准路径的来源有两种一是产品设计时定义的理想链路二是从历史正常日志中统计出的高频路径。两者结合会更准确。6.2 路径偏离检测器有了标准路径就可以写一个简单的路径检测器判断实际路径是否发生了偏离。# 文件路径detection/detour_detector.py from typing import List def classify_route(actual: List[str], standard: List[str]) - str: 判断实际执行路径相对于标准路径的类型。 返回 normal / path_lengthened / skill_replaced / unrelated_skill if actual standard: return normal if len(actual) len(standard) and set(standard).issubset(set(actual)): return path_lengthened if len(actual) len(standard) and set(actual) ! set(standard): return skill_replaced return unrelated_skill if __name__ __main__: standard [extract_keywords, summarize] actual_1 [extract_keywords, summarize] actual_2 [extract_keywords, web_search, deep_rerank, summarize] actual_3 [summarize, deep_rerank] print(actual_1, -, classify_route(actual_1, standard)) print(actual_2, -, classify_route(actual_2, standard)) print(actual_3, -, classify_route(actual_3, standard))预期输出[extract_keywords, summarize] - normal [extract_keywords, web_search, deep_rerank, summarize] - path_lengthened [summarize, deep_rerank] - skill_replacedpath_lengthened和unrelated_skill都值得关注。前者意味着成本变高后者可能意味着规划器选错了技能。6.3 汇聚检测按路径指纹聚合前面说过Convergent 是这个异常模式的关键特征。要检测汇聚可以按天统计路径指纹频率。# 文件路径detection/convergence_detector.py from collections import Counter from detection.detour_detector import classify_route def detect_convergence(path_logs, standard_routes, top_k5): path_logs: list of dict, 每项包含 task_id 和 actual_path fingerprint_counter Counter() anomaly_counter Counter() for log in path_logs: task_type log.get(task_type) actual log.get(actual_path, []) standard standard_routes.get(task_type, []) fingerprint -.join(actual) fingerprint_counter[fingerprint] 1 if standard: route_type classify_route(actual, standard) if route_type ! normal: anomaly_counter[fingerprint] 1 print(高频路径指纹 Top, top_k) for fp, cnt in fingerprint_counter.most_common(top_k): print(f{fp}: {cnt}) print(\n异常路径指纹 Top, top_k) for fp, cnt in anomaly_counter.most_common(top_k): print(f{fp}: {cnt})当某条非标准路径指纹同时满足三个条件时应该触发告警出现次数进入 Top N。平均资源消耗明显高于标准路径。路径中包含多个重型技能。6.4 阈值与告警告警阈值需要根据业务数据不断校准。初期可以先采用保守策略单任务技能数量超过标准路径数量 1.5 倍时记录为“路径延长”。当天异常路径指纹的总占比超过 10% 时触发运营告警。单个外部 API 的调用次数环比增长超过 200% 时触发成本告警。这些阈值不是固定的需要结合测试环境验证和线上基线动态调整。7. 防护建议与工程实践7.1 技能注册表设计技能注册表不仅是一个列表它应该包含防御性元数据。建议为每个技能补充以下字段复杂度等级low / medium / high。是否允许子调用。是否允许调用外部网络。单次任务最大调用次数。预估成本等级。示例配置如下# 文件路径config/skill_policy.yaml skill_policy: budget: max_external_api_calls: 10 max_estimated_tokens: 4000 max_execution_ms: 30000 whitelist: enabled: true skills: - name: extract_keywords complexity: low allow_child_calls: false allow_external_network: false - name: web_search complexity: high allow_child_calls: false allow_external_network: true - name: deep_rerank complexity: high allow_child_calls: true child_limit: 3这套配置的核心思路是默认限制按需放开。低复杂度技能不允许子调用重型技能在明确允许的情况下才能展开子链路。7.2 双层预算控制预算是防止资源放大的最后防线。建议在规划器和执行器两层分别做控制规划器层要求模型在生成计划时附带预估成本如果预估成本超过阈值直接要求重新规划。执行器层运行时统计实际 token 和外部 API 次数一旦超过预算终止后续调用并进入降级流程。执行器层尤为重要因为规划器的预估不一定可信。预算控制本质上是对概率模型行为的一种强制约束。7.3 熔断与人工审批对于高风险技能可以设置熔断机制。当某个技能在短时间内被异常高频调用时自动熔断该技能并降级为备用技能或返回提示。这里要注意任何熔断和降级策略都应该先在测试环境验证并且要保留人工审批入口避免误伤正常业务。7.4 版本灰度与回滚如果异常是由技能描述或路由提示词调整引起的可以通过灰度发布来降低影响范围。建议流程是先在影子环境或小流量阶段观察路径指纹分布。对比新版本与旧版本在相同任务上的路径差异。如果出现新的高成本路径回滚配置。所有配置变更必须有版本记录方便追踪。7.5 审计日志与最小权限在生产环境中技能执行日志应保留足够长的时间作为事后审计依据。同时每个技能应该按最小权限原则配置访问范围避免一个被异常调用的技能连带触发高权限操作。尤其是涉及数据库、支付、消息发送等敏感操作时必须增加人工审批或二次确认不能完全交给模型自主判断。8. 常见问题与排查思路这里总结几个我在实践中遇到过的问题以及对应的排查思路。问题现象常见原因解决思路token 消耗突增但任务成功率不变规划器选择了更长的技能路径按任务 ID 展开调用链对比标准路径定位新增技能外部 API 调用次数翻倍技能内部重试或分页逻辑触发检查技能实现限制重试次数和单次拉取量多轮对话后延迟明显上升历史上下文被反复作为输入为中间结果建立缓存判断是否可以复用历史执行结果不同任务都调用同一个重型技能技能描述过于宽泛规划器过度选择细化技能描述增加复杂度等级和调用限制发布新技能后整体成本上涨新技能与旧技能语义重叠检查技能注册表合并或下线重复技能排查时建议遵循以下顺序先按任务 ID 拉取完整执行路径。确认路径是否偏离标准路径。定位新增技能的触发条件。查看技能内部是否有重试、分页、子调用。最后评估是规划器问题还是技能实现问题。9. 总结这次排查经历让我形成了一套比较稳定的处理思路任务成功不代表执行健康执行路径本身就是需要监控的核心对象。围绕 Convergent Detour Hijacking 这个模式我们可以在工程上做三件有价值的事情第一建立完整的技能调用链记录让任何一次资源放大都有迹可循。第二维护标准路径库用规则和统计检测“绕路”行为。第三在技能注册表和执行器层加上预算控制把资源消耗限制在可控范围内。如果你正在设计基于技能的 LLM 智能体建议一开始就把路径指纹、资源消耗、外部依赖调用次数纳入监控体系而不是等到账单异常后再排查。后续可以继续深入研究的方向包括路径指纹的聚类分析、基于历史基线的成本预测以及更细粒度的技能预算编排。如果这篇文章对你有帮助可以收藏备用。如果你在项目中遇到过类似的路径绕路问题也欢迎在评论区分享你的排查思路。