agent-skills工程化指南：让AI Agent从“会聊天”到“会干活”

RC-1136

316人浏览 · 2026-10-05 10:37:45

RC-1136 · 2026-10-05 10:37:45 发布

1. 从概念到落地：agent-skills 到底在解决什么问题

这两年聊 AI Agent，大家已经不再纠结“能不能跑通”，而是开始焦虑“怎么让 Agent 稳定、可控、可复用”。我自己的体会特别深：上半年花了两周做了一个带工具调用的 Agent 原型，演示的时候效果炸裂，领导当场拍板要落地。结果一进入真实业务场景就翻车——同样的任务换个说法就理解偏了，工具调用顺序偶尔错乱，跑几次之后上下文一长，前面的关键信息全被冲淡。最后那个项目没上生产，但给我留下了几个很深的教训： Agent 能力的下限由模型决定，上限却由工程决定 。而工程化最核心的一环，就是把“会聊天”的模型，改造成“会干活”的系统。

agent-skills 这个名字，乍一看像是某个开源库或者框架模块，但拆开理解，它代表的是一整套 Agent 技能编排体系： 如何定义技能、如何注册工具、如何让模型在合适的时机调用合适的技能、如何管理多轮对话中的状态与记忆、如何从失败中自我修正 。这不仅仅是写几个函数然后告诉模型“你可以用”那么简单，它涉及的是 Agent 架构设计、提示词工程、器用（工具）抽象、记忆策略、行为评估等多个层面的协同。

我见过不少团队在这个环节踩坑。最常见的情况是：一开始把 Agent 当成“超级聊天机器人”来做，给模型塞了一堆函数定义，指望它自己理解什么时候该调什么。结果就是：简单任务能完成，复杂任务要靠运气；偶尔调对一次工具就觉得成功了，但换一批数据又完蛋。说白了， 没有技能编排概念的 Agent，就像没有一个完整工具箱的新手，手里拿着锤子，看什么都像钉子 。

这篇文章，我从自己的实操经验出发，把 agent-skills 对应的核心设计思路、工具抽象方法、记忆管理策略、任务拆解与执行管线的搭建方式，一点点拆开讲清楚。不追求大而全，但求把关键的坑和解决思路都说到位。适合已经在做 Agent 开发、或者正准备从原型走向生产的工程师参考，也适合对 Agent 架构感兴趣的产品和技术负责人读一读，方便和组织里的研发团队对齐认知。

2. 核心设计思路：先把 Agent 当成“有手有脚的员工”，而不是“更聪明的聊天框”

2.1 技能（Skill）到底是什么

在 agent-skills 的语境里，技能不是代码里的一个函数，而是 模型可以调用的一组能力单元，每个单元有明确的触发条件、输入输出契约、执行逻辑和失败处理策略 。我用一个类比来解释：你把 Agent 想象成一个新入职的运营专员，他需要会写文案、会做数据透视表、会发邮件、会查排期。这些能力不是靠他“临场发挥”的，而是公司给他配了操作手册、模板和系统权限。技能就是这套东西的数字化版本。

一份完整的技能定义，至少包含四层信息：

第一层是 触发条件 。什么时候该用这个技能？比如“当用户提到查询订单状态时，应该先调用订单查询工具，而不是让模型凭记忆瞎编”。这层信息决定了模型在什么时机点“伸手拿工具”。

第二层是 输入输出契约 。工具需要哪些参数？参数类型是什么？哪些是必填，哪些是选填？输出格式是什么——是 JSON、表格还是普通文本？这层信息决定了工具能不能被模型稳定地调用。很多翻车案例，问题不是模型笨，而是工具的定义含糊，模型根本不知道参数该传什么。

第三层是 执行逻辑 。这里有两种做法，一种是工具本身只是函数封装，执行逻辑完全由代码决定，模型只负责传入参数；另一种是工具内部也有简单的逻辑分支，由模型传入额外指令来驱动。第一种更稳妥，第二种更灵活，但风险也更高。

第四层是 失败处理 。工具返回异常怎么办？超时怎么办？参数校验不过怎么办？模型必须知道这些情况下该怎么反馈给用户，或者尝试换一种方式达成目标。

注意：技能定义的核心原则是“契约先行”。很多团队一开始就把工具函数写得爽，参数随意、返回结构不固定，结果模型在调用时经常猜错。我在实践中发现，工具定义先写清楚，比模型提示词写得花哨有用十倍。

2.2 工具抽象的三个层次：能力、接口、策略

工具抽象如果只做一层，后面扩展会非常痛苦。我个人习惯把工具的抽象拆成三个层次，这样可以兼顾灵活性和可控性。

能力层 是最底层，它描述的是“系统能做什么”，比如“查询天气”“发送邮件”“读取数据库”。在这个层面，技术细节还不必暴露，只定义能力的边界和依赖的资源。

接口层 是模型真正面对的东西。在这里，每个能力被包装成一个函数描述，包含名称、描述、参数 schema。接口层的设计需要遵循一个原则： 让模型“一看就懂，一猜就对” 。函数名称要语义化，描述要短而精确，参数名要符合直觉。比如同样一个查询订单工具，接口层写成“query_order(status: string, user_id: string)”，比写成“exec_cmd(type=1, paramA=xxx)”要靠谱得多。

策略层 是很多人忽略的一层。它定义的是“在什么条件、什么优先级下调用哪些能力”。比如有的任务需要先查数据再发邮件，有的任务需要先做权限校验再读文件。策略层可以是代码写死的规则，也可以是由模型基于对话历史动态决策的策略，还可以是两者的结合。

我见过不少团队只在接口层下功夫，把函数描述写得天花乱坠，但策略层完全交给模型自由发挥。结果呢？工具是都能调，但顺序经常错，该先做的事没做，不该先做的事情反而先做了。 原因很简单：模型擅长在给定约束下做选择，但不擅长凭空建立复杂的流程约束。 所以策略层的设计越明确，Agent 的行为就越稳定。

2.3 技能与提示词的关系：别把希望全押在 System Prompt 上

一开始做 Agent 的时候，我也犯过把什么都往 System Prompt 里塞的毛病。技能说明、工具列表、使用规则、输出格式、注意事项……一股脑全写进提示词。结果就是：模型上下文被占掉不少，但关键的规则反而没有真正被遵守。后来我把思路改了， 把技能定义从提示词中剥离出来，作为独立的结构化配置管理，提示词里只保留角色的身份和行为原则 。

这里有一个非常重要的发现：模型对工具定义的理解能力，其实取决于工具的语义是否与模型的预训练知识对齐。什么意思？比如模型在训练语料里见过无数种“get/post”“query/user_id”的表达，那接口层写成这样它就理解得很快。但如果某个工具的命名和描述特别小众，模型就倾向于忽略它。所以 工具描述要尽量用通用语言、通用概念，要站在“让模型容易理解”的角度去写，而不是站在“让代码优雅”的角度去写 。

另外，技能相关的指令不应该分散在多处。你把它放在 System Prompt 里、User Message 里、还是工具描述里？经验是： 核心策略放 System Prompt，工具契约放接口定义，临时指令放对话上下文 。这样层次分明，模型不会混淆，也方便你在工程上做日志追踪。

3. 核心细节解析：技能编排中最容易忽视的五个关键维度

3.1 上下文管理：Agent 的“工作记忆”怎么设计

上下文管理是我在 agent-skills 落地过程中觉得最重要、也最容易出问题的部分。很多 Agent 跑着跑着就“失忆”——前两轮说过的事情，后面忘了。这不是模型笨，而是上下文窗口有限，早期信息被后续内容挤掉了。

我常用的做法是三层记忆结构。 短期记忆 保存当前任务的对话切片，一般不超过最近十轮； 工作记忆 保存当前任务的关键变量，比如用户填写的表单信息、查询到的中间结果、已经确认的约束条件； 长期记忆 保存跨会话的事实，比如用户的偏好、历史任务的结论、业务规则的变更。这样的分层设计，能让模型聚焦当前任务，又不至于丢失关键背景。

你可能会问，长期记忆怎么存？我的方案是：不直接存原始对话文本，而是存结构化的事实摘要。给每条摘要打上标签，比如“用户偏好”“项目信息”“历史决策”，然后按需检索。这样既节省 token，又不会因为原始文本太冗余导致信息淹没。

注意：短期记忆一定要控制长度。我见过有团队把整场对话的 transcript 全部塞进上下文，结果中期信息反而被压在后面，模型总是只关注最后几轮。正确做法是每轮对话结束后做一次摘要压缩，保留结论、关键事实、未完成事项，丢弃细枝末节的措辞。

3.2 任务拆解：把复杂目标变成可执行的技能序列

Agent 要完成一个复杂任务，不能只有一个“大招”，而是需要一组技能的配合。以“帮用户制定一份旅行计划”为例，你会需要：获取日期和目的地（对话技能）、查询航班（航班搜索工具）、查询酒店（酒店搜索工具）、计算总预算（计算技能）、生成行程表（文档生成技能）。这个流程的编排方式，决定了 Agent 是像一位靠谱的旅行顾问，还是一个手忙脚乱的新手。

任务拆解有两种主流模式。 一种是显式规划 ：模型先输出一份计划，列出任务步骤和每一步需要用到的工具，然后系统逐步执行。这种方式可解释性强，但容易呆板，遇到计划外情况反应不过来。 另一种是隐式规划 ：模型不输出完整的计划，而是每一步基于当前状态选择下一步动作。这种方式灵活，但难点在于如何约束模型不跑偏。

我的习惯是混用。对流程相对固定的任务，提前写好模板，用显式规划的方式执行；对开放性强的任务，设定好边界条件，让模型动态决策。比如在客户支持场景中，退款流程是固定的，就走显式规划；而处理投诉这种开放性问题，就允许模型灵活组合技能。

3.3 状态机：Agent 运行的“交通规则”

很多人写 Agent 的时候忽略了状态管理，结果 Agent 像个没有方向盘的车，跑得快但方向不稳。状态机是一个很实用的方案。简单说，就是定义几个核心状态，比如“收集信息”“确认意图”“执行工具”“生成回复”“等待反馈”，每个状态下只允许执行特定的技能。

举个例子：用户说“帮我订一张明天去北京的机票”。如果 Agent 直接去调用订票工具，那就出问题了——因为还没有确认出发时间、舱位偏好、预算上限。正确的做法是先进入“收集信息”状态，把必要的参数问全，再进入“确认意图”状态，把行程摘要给用户确认，最后才进入“执行工具”状态，调用订票接口。

状态机的引入，能在很大程度上解决模型“过于自信”的问题。模型常常会基于不完整的信息就做出判断，这是大语言模型的通病。有了状态机约束，你就可以在代码层面阻止它“过早行动”。

实操心得：状态机不要设计得太复杂，五到八个核心状态足够了。状态多了反而让模型困惑，因为每一步都要判断当前状态是否符合预期。保持状态精简、迁移条件清晰，是 Agent 稳定的关键。

3.4 工具调用的重试与自省机制

工具调用不是一次就能成功的。网络超时、参数格式错、权限不足、返回结构变化，各种问题都可能发生。好的 agent-skills 系统，必须具备“失败-重试-自省-修正”的闭环能力。

我在实践中采用了一套“三段式重试”策略。 第一段 ：工具调用失败后，先用简单规则判断——是参数问题？超时问题？还是权限问题？根据错误码分别处理。 第二段 ：如果是参数问题或逻辑问题，将错误信息回传给模型，并附带上下文摘要，让模型自己判断哪里不对、如何修正。 第三段 ：如果模型连续两次修正仍然失败，就切换到兜底策略——明确告知用户当前无法完成，并引导用户换一种方式，或者转接人工。

这里有个细节很多人会漏掉： 错误信息本身也要设计 。工具返回的异常信息，应该包含“发生了什么”“可能的原因”“建议的处理方式”三要素。这样模型拿到之后，才能做出有价值的自省判断。如果你只是返回一个 internal error ，那模型只能瞎猜，重试多少次都没用。

3.5 技能的可观测性：没有日志就没有优化

Agent 的能力优化，不能靠拍脑袋，必须靠数据。所以我从第一天就在所有技能调用链路上埋了日志和追踪点。每个技能调用都记录：触发时的对话上下文摘要、传入的参数、返回的结果、耗时、是否成功、模型决策的理由（如果模型输出了 reason 字段）。这批日志是后续调优最重要的原材料。

有一次排查一个“Agent 在某个场景下频繁调用错误工具”的问题，我就是通过日志发现：模型在某个特定语境下会被工具名称中的某个词误导，连续 80% 的请求都调了错误工具。后来把工具名称改了一个措辞，问题立刻消失。如果没有日志，这种问题根本定位不到。 可观测性不是锦上添花，而是 Agent 工程的底线 。

4. 实操过程：从零搭一套标准技能编排管线的完整步骤

4.1 第一步：定义业务场景与能力清单

在写任何代码之前，先拿一张纸，列出你希望 Agent 能完成的完整任务清单。不要泛泛地写“客户支持”，要写具体任务——“查订单状态”“修改收货地址”“申请发票”“退货退款”“投诉升级”。

每个具体任务背后，再拆一层，列出完成它所需的原子能力。比如“申请发票”需要：获取用户身份信息、查询订单详情、验证发票规则、调用发票系统接口、反馈结果。到这里，能力清单就清晰了。

这一步的价值在于：它帮你提前发现能力缺口。比如你发现“退货退款”需要调用 ERP 系统，但你们公司 ERP 接口的权限还没申请下来——那这个就得提前协调，而不是等 Agent 做完了发现后端不通，再回头补。

4.2 第二步：设计技能工具接口层

基于第一步的能力清单，开始定义工具接口。我给一个具体的例子，假设你在做一个“团队助手”类 Agent，其中一个核心技能是“安排会议”。

接口可以这样定义：

def schedule_meeting(
    title: str,              # 会议标题
    start_time: str,         # 开始时间，ISO 8601 格式
    end_time: str,           # 结束时间，ISO 8601 格式
    attendees: list[str],    # 参会人邮箱列表
    description: str = "",   # 会议描述
    location: str = ""       # 会议地点（线上/线下）
) -> dict:
    """
    安排一场新会议。

    Args:
        title: 会议标题，必填。
        start_time: 会议开始时间，格式如 "2025-06-01T10:00:00+08:00"。
        end_time: 会议结束时间，格式同上。
        attendees: 参会人列表，至少包含一人。
        description: 会议描述，选填。
        location: 会议地点，选填，默认为空。

    Returns:
        成功时返回 {"status": "success", "meeting_id": "xxx", "meeting_url": "xxx"}
        失败时返回 {"status": "error", "error_code": "xxx", "message": "详细错误说明"}
    """
    pass

注意几个细节：参数名尽量用通用的、模型预训练语料中常见的词；类型一定要声明；描述字段要说明格式和边界条件；返回值结构要固定，错误信息要带错误码和可读信息。这些细节直接决定了模型调用工具的准确率。

工具定义好之后，下一步是把它转成模型 API 能识别的格式。以 OpenAI Function Calling 格式为例，上面这个函数可以转成：

{
  "name": "schedule_meeting",
  "description": "安排一场新会议，需要提供会议标题、开始时间、结束时间和参会人列表。",
  "parameters": {
    "type": "object",
    "properties": {
      "title": {"type": "string", "description": "会议标题，必填"},
      "start_time": {"type": "string", "description": "会议开始时间，ISO 8601 格式"},
      "end_time": {"type": "string", "description": "会议结束时间，ISO 8601 格式"},
      "attendees": {"type": "array", "items": {"type": "string"}, "description": "参会人邮箱列表"},
      "description": {"type": "string", "description": "会议描述，选填"},
      "location": {"type": "string", "description": "会议地点，选填"}
    },
    "required": ["title", "start_time", "end_time", "attendees"]
  }
}

实操贴士：如果你的工具数量超过 20 个，建议不要一次全部塞给模型。先把工具按场景分组，每一轮只暴露当前场景可能需要的 5~8 个工具。这样既能降低模型的决策难度，也能减少 token 消耗。很多平台支持动态工具注入，你可以用“意图识别-工具筛选-注入调用”的管线来实现。

4.3 第三步：设计任务执行的主循环

Agent 执行任务的核心循环，我习惯用伪代码描述：

接收用户输入，追加到对话历史。
判断当前状态（来自状态机）。
基于当前状态和对话历史，筛选可用技能集。
调用模型，传入对话历史、可用技能集、当前状态信息，让模型决定下一步动作（是调用工具、追问信息、还是生成最终回复）。
如果模型决定调用工具，执行工具，将结果附加到对话历史，回到第 2 步。
如果模型决定追问信息，把追问内容返回给用户，等待用户回复，回到第 1 步。
如果模型决定生成最终回复，校验是否满足任务完成条件（比如必要参数是否齐全、工具是否执行成功），满足则输出，不满足则回到第 4 步。

这个循环看起来不复杂，但实现的时候有几个关键点。第一， 工具的返回结果要“加工”后再放回对话历史 ，不能直接把原始 JSON 丢给模型。我做了一层 result formatter，把工具返回的 JSON 转成自然语言摘要，再加上必要的执行状态说明。原因很简单：模型看自然语言文本的理解效率，远高于看嵌套 JSON 的效率。

第二， 循环要有最大步数限制 。我一般控制在 15~20 步以内。如果超过步数还没完成，就强制终止，告诉用户当前任务需要人工介入。这是防止 Agent 陷入死循环的保险丝。

第三， 每轮循环都要做一次结果评估 。不是等整个任务结束再评估，而是每步都判断“这一步的输出是否合理”。合理就继续，不合理就触发修正逻辑。这个评估可以是基于规则（参数校验、时间校验、金额校验），也可以再调用一次模型做判断。前者便宜快速，后者更聪明但更贵。我一般先用规则，规则覆盖不了的再用模型辅助判断。

4.4 第四步：搭建记忆模块

记忆模块我在前文已经说了三层结构，这里补充实现方案。

短期记忆 ：直接在对话历史里组织，设置最大轮数，超出后用摘要压缩。

工作记忆 ：用 JSON 对象维护一个“任务状态表”。比如：

{
  "task_type": "travel_planning",
  "collected_params": {
    "destination": "北京",
    "departure_date": "2025-06-10",
    "return_date": "2025-06-13",
    "budget_max": 5000
  },
  "pending_items": ["酒店预订", "航班预订"],
  "confirmed_items": ["目的地-北京", "时间-6月10日至13日"]
}

工作记忆的好处是：即使对话历史被压缩了，关键参数仍然保留。每次模型需要决策时，把工作记忆作为结构化上下文注入，它就知道当前进度在哪里。

长期记忆 ：可以使用向量数据库存储事实摘要，按用户或按项目做分片，在需要时用相似度检索把相关信息拉回上下文。这里要注意的是，检索结果也要做摘要压缩，不能整段塞回去，否则用户消息还没被处理，上下文窗口就被旧记忆占满了。

4.5 第五步：配置提示词与行为策略

提示词的设计原则，我用一句话总结： “少讲道理，多给规则。” 不要在提示词里长篇大论解释 Agent 是什么、能做多少事，而是用清晰的条件句定义行为边界。

举个例子，我写过一个客服 Agent 的 System Prompt 核心部分：

你是一名在线客服助手。你只能使用已提供的工具来完成任务，禁止凭猜测编造信息。

当用户请求涉及下列操作时，必须按对应流程执行：
- 查询订单：先调用 get_order_info 获取订单详情，再基于详情回答。
- 修改地址：先获取用户身份信息，再调用 update_shipping_address，并返回修改结果。
- 申请退款：先确认订单状态，再调用 refund_request，退款结果以接口返回为准。

如果用户的需求不在你的能力范围内，明确告知用户“当前我无法处理此事，将为你转接人工客服”，并调用 escalate_to_human 工具。

所有回复必须使用中文，语气友好但不啰嗦。回复中不得包含具体接口字段名、HTTP 状态码等技术细节。

这种写法有一个好处：模型的行为边界非常清晰。它不是在“扮演”一个客服，而是在“遵守一套规则”的模式下工作。两者有本质区别。

另外，提示词也可以加入“执行前检查清单”。比如在生成最终回复之前，要求模型内部自查三个问题：所有必要信息是否已经获取？所有关键工具调用是否成功？回复是否直接回答了用户的原始问题？这个检查逻辑可以通过 few-shot 示范来强化。

4.6 第六步：端到端联调与边界测试

当所有模块都搭好之后，进入联调阶段。这里的重点是“边界测试”，不是“常规测试”。我会针对每一类技能，设计一批刁钻的输入：

参数缺失的情况（用户只说了结果没给条件）
参数冲突的情况（用户说的时间与系统时间冲突）
工具返回异常的情况（接口宕机、权限不足、余额不足）
用户情绪激动的情况（连续质疑、换着方式说同一件事）
多任务并发的情况（一个会话里同时涉及查单和改地址）

每一条测试用例，都要记录：预期行为、实际行为、是否触发异常、模型决策是否正确、最终输出是否合理。边界测试跑完，Agent 的稳定性和可用性才会有基本保障。

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

5.1 模型总是不调用工具，或者调错工具

这是最常见的故障。排查思路按顺序来：先看工具描述的语义是否清晰、有没有歧义词；再看工具名称是否与模型预训练语料中的常见表达一致；再看当前场景暴露的工具集是否太多，干扰了模型判断；最后看提示词中是否明确给出了“在什么条件下调用什么工具”的规则。

我遇到过一个案例，工具名称叫 process_refund_request ，模型总是把它和 create_return_order 搞混。后来我分析日志发现，两个工具描述都出现了“订单”和“退款”关键词，模型在语义上不好区分。修复方案是把描述改成完全不同的表达重点——一个强调“退款到原支付账户”，一个强调“生成退货物流单”。改了之后，调错概率从 30% 降到了 2% 以下。

5.2 对话进行到一半，Agent 突然“失忆”

这个问题大概率是短期记忆的截断策略导致的。如果你用“最后 N 轮”做截断，但截断时没有做摘要压缩，那么中间的关键信息就丢了。建议在每次截断前，先调用一次摘要函数，把关键参数、用户明确表达过的偏好、尚未完成的任务提取出来，写入工作记忆，然后再丢弃旧内容。

另外，还有一种情况是：模型在一次调用中输出结果过长，挤压了下一次决策的注意力。这个可以通过限制最终回答的长度来缓解，比如要求回复不超过 200 字，这样可以把上下文留给工具调用和状态推理。

5.3 工具调用成功了，但 Agent 给用户的回复是错误的

这个问题很隐蔽，通常是结果 formatter 出的问题。如果你把工具返回的 JSON 原封不动塞给模型，模型很可能在“翻译”时出错。比如数字字段被模型四舍五入、状态字段被翻译错了、时间格式被模型改成了另一种表达。

我的建议是：工具返回的结果，在交给模型之前，先用代码做一次“防错处理”。具体来说，把关键结果用模板文本固定下来，再补充一些解释性文本。比如订单查询工具返回 {"status": "shipped", "eta": "2025-06-15"} ，formatter 会把它转成“订单状态为已发货，预计送达日期为 2025 年 6 月 15 日。请基于以上信息回答用户问题。”这种固定模板比原始 JSON 更安全，模型不容易篡改关键事实。

5.4 Agent 在复杂任务中陷入重复循环

我在 4.3 节提过最大步数限制，这是兜底方案。但更好的方式是从策略上避免循环。具体做法：让模型每一步都要输出一个“当前进展说明”，并把上一步的进展摘要注入下一步的上下文。这样模型能看到自己已经做了什么、还有什么没做，就不容易原地打转了。

还有一个实用技巧：在提示词中写一条规则—— “如果下一步动作与上一步动作完全相同（调用同一个工具、传入同样的参数），必须先说明原因。若没有正当理由，不得重复调用。” 这条规则能有效抑制大部分无意义循环。

5.5 多工具协作时，参数传递断层

一个任务需要多个工具接力完成时，经常出现前一个工具的输出是后一个工具的输入，但这个传递不顺畅。比如先查询用户信息，再用用户信息去查询订单，但模型在生成第二步工具调用时，把用户 ID 传成了“null”或“unknown”。

解决办法有二。一是代码层做强制传递，把前序工具输出的关键字段提取到工作记忆，并在后一个工具的参数描述中注明“如用户 ID 已经获取，请直接从工作记忆中读取，不要询问用户”。二是 prompt 层做示范，我在 few-shot 里特意加了这种接力场景的示例，模型学得很快。

5.6 日志记录很全，但不知道怎么分析

这是个很现实的问题——Agent 日志可能一天几十万行，靠人肉翻是不现实的。我的方案是：给每个会话、每个任务分配一个 task_id ，给每个工具调用分配一个 trace_id 。日志按 task_id 聚合，再用一套简单的统计脚本，计算每个场景的成功率、平均步数、工具调用次数分布、失败原因 TOP 榜。这些数据能直接指导你优化哪一个环节。

如果你团队里有数据分析能力，还可以把日志里的关键特征接入一个可视化面板，实时展示 Agent 的行为分布。哪怕只看“哪些工具最常被调用”“哪些工具失败率最高”，也能快速定位优化重点。