开始:我其实一直觉得很多人玩 Agent 玩到最后卡住的不是模型不够聪明也不是框架不够先进而是——你每次让它干活都得把前因后果重新讲一遍。比如你想让它帮你整理周报你得说“帮我把这几天的记录汇总一下按项目分一下类再给出下周重点建议顺便把风险也标出来最后用表格排版记得语气正式一点……”第一次这么调教还行第二次、第三次你还真有耐心每次都重复一遍反正我没有。所以这一篇系列第 4 篇我想专门聊聊 Agent 的「技能」到底是怎么回事。简单来说技能就是把你每次都要从头讲一遍的流程变成一句话就能启动的东西。这篇我会拆开讲清楚技能的本质、设计思路、落地方案以及在真实使用中会踩到的坑。不管你是在用现成的智能体平台还是自己折腾 Python 搭 Agent这篇的思路应该都能用上。1. 技能为什么不是“预设提示词”那么简单很多人一听说技能第一反应是这不就是提前写好的一段 Prompt 吗我把它存下来下次复制进去不就行了这个理解对了一半但只对了一半。如果技能真的只是“一段固定 Prompt”那它根本解决不了“每次流程不一样”的问题——因为你的周报数据每次都不一样你的排查场景每次也不一样技能必须要能接收输入参数并且根据输入动态调整执行过程这才是技能和普通预设提示词的本质区别。另一个区别在于“执行路径”。预设提示词只是把话术写好了但 Agent 具体要做什么步骤、调什么工具、什么时候停下来等你确认这些是没法写死在提示词里的。而技能更像是一个“带参数的执行计划”它里面不仅包含了给模型看的指令还包含了完整的流程定义、所需工具的调用说明、终止条件以及异常处理策略。我用一个比较生活化的类比预设提示词就像你给新来的实习生写了一张便签上面写着“干活要认真、要有条理”而技能则是一份岗位 SOP里面写着“第一步干什么、第二步干什么、遇到什么情况找谁签字、什么情况下直接放弃上报”。这也是为什么很多 Agent 平台会把技能单独做成一个模块而不是简单塞在系统提示词里——它本身要承载的东西远比一段话术要多得多。1.1 技能的组成结构从外部看到的三个层次从用户视角看一个技能通常包含三个层次触发层也就是“一句话启动”的那句话。用户不需要描述步骤只需要说“整理周报”或者“帮我写日报”技能就要能识别出当前应该启动哪个流程。参数层即使是一句话启动技能也需要从这句话里抽取必要的变量。比如你说“整理本周周报”它需要知道“本周”是哪几天、你的数据源在哪、输出格式是 Markdown 还是表格。这些信息可能来自用户的话也可能来自 Agent 当前所处的上下文比如日期、环境、会话状态。执行层这是技能真正干活的部分。根据参数调用相应工具、检索相应的数据、按既定流程生成内容或执行操作最后把结果格式化后返回。这个结构说起来简单但实际设计的时候最容易出问题的恰恰是参数层——因为用户根本不会按照你预设的格式去说话。你的技能如果只认“时间范围是本周一9:00到本周五18:00”这种整齐的输入那它基本废了因为真实用户只会说“整理一下这几天的”。1.2 从“记忆”角度理解技能的价值还有一个更深的维度技能其实是在帮你节省 Agent 的“记忆”。在大语言模型驱动的 Agent 里上下文窗口是有限资源你每次把完整的流程指令、工具说明、示例输出都塞进提示词里会占用大量上下文空间导致 Agent 在处理真正任务的时候反而变“笨”了——前面废话太多后面正经内容就装不下了。技能相当于把“流程知识”和“当前任务实例”拆开了。流程知识被固化在技能定义里只在调用时加载当前任务的真实数据只针对本次调用单独注入。这个拆分的价值在你跑复杂流程的时候体现得特别明显——上下文干净了模型的推理质量就会有明显提升。2. 把“你要做的是”变成“技能本身”——设计的起点我知道大家最喜欢看的是具体怎么做但在写具体实现之前我必须先聊设计思路。因为我在不少社群里看过翻车案例根源都是设计思路错了。很多人做技能的第一步是先找一个流程然后把流程步骤用大白话写下来再喂给 Agent。这种做法看起来很符合直觉但实际做出来的技能几乎都不好用。原因很直接你把“一个流程”描述出来和把“一个可重复调用的技能”设计出来是两个层面的工作。设计技能之前你得先回答四个问题而且是明确地、用文字写下来那种回答这个技能要解决的问题是什么注意要精确到“输入是什么、输出是什么”而不是“帮用户写报告”这种模糊表述。这个技能和普通对话有什么区别如果用户直接跟 Agent 对话也能达到同样效果那你做成技能就是浪费。这个技能被调用的频率有多高只有高频场景才值得做技能。如果一个月才用一次还不如每次现说。这个技能的边界在哪里哪些情况它处理不了、应该直接拒绝或转人工这是最容易忽略的一点。2.1 高频、重复、有明确规则好技能的场景画像我自己的经验是适合做成技能的场景有三个特征第一高频。这里的“高”是相对你自己的使用频率而言。如果你是做运营的每天都要出数据简报那“数据简报生成”技能就很有价值如果你只是每个月月底汇总一次那真的没必要。第二重复。这个“重复”指的是流程路径一致而不是结果一致。也就是说每次执行时步骤顺序、调用的工具、需要做的判断逻辑都一样只是数据不同、参数不同。如果每次流程都在变、全靠临场发挥技能反而会成为束缚。第三有边界。技能处理的问题域应该是清晰的什么算成功、什么算失败、失败时怎么办都得能说清楚。如果一个问题你自己都想不明白边界在哪那你也没法把它变成技能。2.2 用“技能描述”倒推实现先写使用说明再写代码我自己在做技能设计时有个习惯先写这个技能的“使用说明书”也就是假设它已经做好了用户会怎么描述它、怎么调用它、期望得到什么结果。这份说明书我一般只写三块内容触发条件用户在什么情况下会说哪句话来启动这个技能输入参数启动时用户会提供哪些信息哪些是必填、哪些有默认值输出形式最终返回给用户的是什么文本、表格、文件还是直接执行某个操作写完之后再倒推实现。这样做的好处是你会被迫站在使用者的角度上去想问题而不是站在“这个流程好复杂我要把它全自动化”的角度。流程复杂不是你做技能的理由用户用着顺手才是。2.3 一条重要的经验技能不是越大越好这点我特别想说。接触 Agent 一段时间后很容易染上一个毛病看到什么流程都想做成一个大而全的技能恨不得一个技能把整个工作流全包了。但大技能的维护成本会指数级上升。流程越长出错的环节越多环节越多定位问题就越难定位问题越难你每次使用前的“容错成本”就越高。最后你可能会发现这个技能成了个摆设用起来还不如直接对话。所以我现在的习惯是“一次只做一个动作”原则——一个技能尽量只负责一个完整的、闭环的动作。比如“生成周报”是一个动作“把周报发送到指定群聊”是另一个动作。你可以把多个技能串联起来跑但不要在一开始就把它们揉成一个巨型技能。3. 技能的实际落地路径从平台到编程实现在讨论技能的具体实现之前我想先把当前几种主流的落地路径梳理一下。因为不同背景的人实际能接触到的技能实现方式完全不一样但你理解了整体原理之后无论在哪条路径上思路都是通的。我把它们大致分为三类平台型技能、配置文件型技能、代码型技能。这三类不是互斥的很多场景里它们是混合使用的。3.1 平台型技能适合快速验证和低代码场景现在很多 Agent 平台比如 Coze、Dify 这类都内置了技能机制。这种平台型技能通常是可视化配置的——你可以在界面上定义技能的触发词、参数列表、内部逻辑节点然后发布给整个 Agent 使用。平台型技能最大的价值是门槛低。你不需要写太多代码主要工作集中在“把流程拆成节点”和“把参数配置对”上。我建议刚接触技能概念的朋友先从平台型技能入手因为它的约束环境会逼着你把技能结构想清楚又不会因为代码调试问题打击你的信心。但平台型技能也有明显的局限灵活性不足。一些复杂的判断逻辑、自定义的数据处理流程在可视化配置里会显得非常别扭。这时候就需要往下走一层了。3.2 配置文件型技能把流程定义和代码逻辑分开如果你在用一些更灵活的框架比如某些开源 Agent 项目你会发现它们常常用 Markdown、YAML 或 JSON 文件来定义技能。这些文件把技能的触发条件、参数 schema、步骤流程、工具调用说明都结构化地写出来然后由框架在运行时加载这些定义。我特别推荐这种“配置与代码分离”的方式因为它让技能的迭代成本变得很低。当你想改技能的某个步骤时你只需要编辑配置文件重新加载一下而不需要动整个 Agent 的代码逻辑。这就很像我们把正则表达式和业务逻辑分开一样改规则的地方就应该只放规则不该混着业务逻辑。配置文件型技能也有自己的复杂度主要是你要学会用结构化描述去表达流程。很多人一开始会把配置文件写得像散文一样很长但真正的技能定义应该是高度结构化的、精简的——每一段都有它的用途不会出现那种“引导模型更好地发挥”之类的废话。3.3 代码型技能完全掌控流程的细节最灵活的实现方式就是直接用代码实现技能逻辑。Python 和 Rust 是当前社区里最常出现的两种选择。Python 的好处是生态成熟、上手快。你可以把技能写成一个 Python 模块接收参数输入内部调用外部工具或 API最后返回结构化结果。这种方式给了你最大的控制力什么数据格式、什么错误处理策略、什么重试逻辑全都可以精确控制。Rust 则更适合对性能和并发要求比较高的场景。从热搜榜上也能看到“ai agent 怎么扛并发”这种问题——如果你的 Agent 要被很多人同时使用技能层面就不仅是逻辑问题还牵扯到资源占用、并发安全和运行效率。Rust 在这里确实是很大的优势项但用 Rust 开发技能的学习成本也高不是所有人都需要一上来就上 Rust。我的建议很明确先用 Python 跑通你的第一个技能等到你确实遇到了性能瓶颈或并发问题再考虑用 Rust 去重构那些真正关键的部分。3.4 基于平台构建的智能体 vs 用 Python 构建的智能体这个话题在热搜里被反复问到我也经常在评论区看到平台搭建的智能体与用 Python 搭建的智能体有什么不一样这个差异理解透了对做技能特别重要。平台搭建的智能体优势在于“专业分工明确”。平台把模型调用、工具管理、技能编排、日志监控这些东西都帮你封装好了你专注在业务逻辑上。它的劣势在于平台本身是一个黑盒你的技能受到平台框架的限制——平台没提供的图节点你就用不了平台的工具类型不支持某种协议你就没法扩展。Python 搭建的智能体则相反。底层一切你都可以控制技能可以是你自定义的任意模块工具可以是任意 API 或本地程序。但这种自由是有代价的你不仅要写业务逻辑还得处理模型调用细节、上下文管理、并发控制、错误恢复这些事情。很多时候你会发现写了一堆代码最后真正在跑业务逻辑的部分可能只占三成其他全是胶水代码。那你怎么选我的标准很简单如果项目追求快速上线、验证想法、团队没有太多工程化能力平台型就够如果项目要长期迭代、有特殊的技能逻辑需求、需要深度定制就自己用 Python 搭。两边没有绝对的好坏。3.5 三种路径怎么选一个决策参考表我把决策逻辑整理成了一张参考表你可以在做技术选型的时候拿它来对照。场景推荐路径核心理由快速验证想法、Demo 展示平台型技能配置快、不需要写代码企业内部工具、流程固定配置文件型技能迭代成本低、可维护性好对性能、并发有要求代码型技能优先 Python必要时 Rust可精确控制资源消耗流程复杂、自定义逻辑多代码型技能Python控制力最强没有编程基础纯业务背景平台型技能门槛最低需要离线部署、数据不出内网代码型技能平台通常绑定云端服务4. 一个完整案例把“月度数据简报”变成技能前面的原理讲得差不多了我们落一个具体的案例。我用一个特别常见的场景——“月度数据简报”来演示从零到一做一个技能的过程。月度简报这个场景很典型它每次做的动作都一样都是把数据拉出来、按维度汇总、加一些解读和预测、最后输出文档。但每次的数据不一样用户关注的重点也可能不一样。这非常适合做成技能。4.1 第一步写使用说明书技能的定义文档在做任何技术实现之前先写这份文档# 技能月度数据简报生成 ## 触发条件 用户说出“生成月度简报”“出月报”“这个月的简报”等语句时触发。 ## 输入参数 - report_month必填要生成简报的月份如“2025-04” - focus_metrics选填重点关注的指标列表默认为每日活跃、新增用户、交易额 - compare_previous选填是否与上月对比默认为 true - output_format选填输出格式支持 markdown / html / pdf默认为 markdown ## 执行流程 1. 获取输入月份的全部核心指标数据 2. 将数据按周拆分统计周环比变化 3. 识别异常波动指标给出可能原因推测 4. 生成下月趋势预测 5. 格式化成用户要求的输出格式 ## 边界条件 - 当月数据不足 10 天的不生成趋势预测只输出数据统计 - 数据源不可用时直接返回错误不尝试猜测数据 - 用户明确要求“只要数据不要解读”时跳过第 3、4 步4.2 第二步定义参数 schema技能的输入契约参数 schema 的翻译是“参数的预期结构”它解决的是“技能被启动后系统应该从用户的输入里抽出哪些信息、以什么格式传给执行逻辑”。它就像你的技能和用户之间的一份合同用户侧只要表达意图系统负责把意图转换为结构化的参数。拿上面的案例来说schema 可以定义为{ report_month: { type: string, description: 目标月份格式为 YYYY-MM, required: true, pattern: ^[0-9]{4}-[0-9]{2}$ }, focus_metrics: { type: array, items: {type: string}, description: 重点关注的指标列表, required: false, default: [daily_active, new_users, revenue] }, compare_previous: { type: boolean, description: 是否与上月对比, required: false, default: true }, output_format: { type: string, enum: [markdown, html, pdf], required: false, default: markdown } }这个 schema 的作用是当用户说“给我出 2025 年 4 月的简报重点关注营收”系统会解析出report_month2025-04、focus_metrics[revenue]其余参数走默认值。然后把这些值注入执行流程。4.3 第三步写执行逻辑Python 示例下面给一个简化的 Python 实现框架完整代码太长我保留了主干结构import json from datetime import datetime class MonthlyReportSkill: def __init__(self, data_source, llm_client): self.data_source data_source self.llm llm_client def execute(self, params: dict) - dict: # 1. 参数校验 report_month params[report_month] assert len(report_month) 7, 月份格式必须为 YYYY-MM # 2. 拉数据 raw_data self.data_source.fetch_month(report_month) if raw_data is None: return {status: error, message: 数据源不可用} # 3. 计算周环比 weekly_stats self._calculate_weekly(raw_data, params.get(focus_metrics)) # 4. 边界条件判断 days_count len(raw_data.get(daily_records, [])) include_forecast days_count 10 # 5. 生成解读调用 LLM analysis if params.get(compare_previous, True): analysis self._generate_analysis(weekly_stats, params.get(focus_metrics)) # 6. 格式化输出 output self._format_output( weekly_stats, analysis, include_forecast, params.get(output_format, markdown) ) return {status: success, data: output} def _calculate_weekly(self, data, metrics): # 这里做周维度的汇总计算 # 省略具体实现但核心是按 ISO 周数分组然后聚合 pass def _generate_analysis(self, stats, metrics): prompt self._build_analysis_prompt(stats, metrics) result self.llm.chat(prompt) return result def _format_output(self, stats, analysis, forecast, fmt): if fmt markdown: # 转成 Markdown 表格 pass elif fmt html: # 转成 HTML 模板 pass elif fmt pdf: # 调用转换接口 pass我刻意把具体的计算逻辑留空了因为不同公司对“周环比”的定义都不一样——你没必要照抄我的实现重点要看清楚的是结构先校验参数再拉数据再算指标再判断边界再生成解读最后格式化输出。每一步之间的数据依赖是清晰的每一步都有返回检查最后一个环节出错不会把前面的数据弄丢。4.4 第四步注册技能并配置触发规则执行逻辑写完最后一步是把这个技能注册到 Agent 上。这一步在不同平台上的操作方式不一样但本质都是三件事告诉 Agent 存在一个叫“月度数据简报生成”的技能告诉 Agent 这个技能接收哪些参数、每个参数怎么从用户的输入里抽取告诉 Agent 什么时候应该调用这个技能、什么时候不应该调用这三件事里第三件最容易被忽略。很多 Agent 会在用户问“上个月收入怎么样”的时候也去触发“简报生成”技能——其实这个时候用户只是想要一个数字没必要跑完整简报流程。解决这个问题的办法通常是在技能描述里写明确切的边界。比如这句描述就有用得多“当用户要求生成月度简报文档或需要结构化展示时使用。如果用户只是询问某个指标的具体数值不使用此技能。”平台在加载技能时是能读到这些描述并用于决定是否触发技能的。5. 技能运行的核心机制触发、调用、反馈的闭环很多教程会给你展示怎么配置技能、怎么填写描述但少有人告诉你配置完之后Agent 内部到底是怎么把“技能”这件事跑起来的。如果你不理解这个机制遇到“技能没有被触发”“技能触发了但参数传错了”这类问题时你会完全没有排查思路。技能从启动到结束在 Agent 内部经历了一个完整的闭环。我把它拆成四个阶段来解析。5.1 触发阶段从意图识别到技能关联当用户输入一句话时Agent 做的第一件事不是执行技能而是理解这句话的意图。这个理解过程大致分为两步快速分类和匹配。在快速分类阶段Agent 会判断这句话到底是普通闲聊、知识问答、还是某个可执行任务的指令。如果是后者它就会进入技能匹配环节。技能匹配的依据通常是“技能描述”和“技能名称”与用户输入之间的语义相似度。这里我给你们划个重点技能描述写得是否准确直接决定了匹配成功率。很多人的技能描述又长又笼统比如“用于管理各种报告生成场景提高效率”——这在匹配时几乎没有区分度。更好的做法是直接写清触发场景“用户说‘出月报’‘本月简报’时使用”。5.2 参数抽取阶段从自然语言到结构化输入技能被匹配上之后Agent 需要完成另一种转换把你的自然语言输入转换成技能要求的参数格式。这个转换通常是由大模型完成的。Agent 把你的话和技能的参数 schema 一起给到大模型让模型从中抽取字段。如果抽取失败或缺失必填参数Agent 通常会反问用户补充信息。这里常见的问题是参数描述不清晰导致模型总是填错。比如你定义了一个参数叫month描述是“目标月份”模型是能理解的但如果你定义的参数是billing_cycle_start描述是“结算周期的开始时间所在月份若跨月则取结束月份”——模型就很容易填错了。所以我的习惯是参数命名尽量直白参数描述里带上一到两个“用户可能会怎么说”的例子。比如report_month的描述可以写成“目标月份格式 YYYY-MM。例如用户说‘出一下今年四月的报’此处填 2025-04。”5.3 执行阶段流程编排与工具调用参数抽取完成之后技能进入正式执行。这一步在不同的实现路径里差异比较大。在平台型技能里执行就是沿着你配置的节点图一个一个跑。在代码型技能里执行就是调用你写好的execute方法。无论哪种形式核心问题都是流程编排——下一步该执行什么、上一步的结果怎么喂给下一步、某一步失败了要不要中断。我特别想提醒的是在执行阶段一定要给 Agent 或技能逻辑保留“重试”的余地。比如你调用一个第三方数据接口网络偶发超时是正常的如果你没有重试机制这个技能就会在执行中途抛错给用户的体验就是“技能坏了”。但在重试之前你得先区分哪些错误可以重试网络抖动、服务暂时不可用哪些错误重试也没用参数错误、权限不足。后者应该优雅返回错误而不是傻傻地重试五次。5.4 反馈阶段结果回落与上下文回填技能执行完返回的结果通常会重新注入到 Agent 的主对话流中让 Agent 基于这个结果继续和用户交互。这里有一个很多人没注意到的细节技能返回的结果不要是一坨巨大的原始数据而应该是“经过整理的、带摘要的结果”。因为 Agent 回填这些结果之后还要基于它生成给用户看的最终回复。如果技能返回了 20 页的原始日志模型生成回复时会被大量无关信息干扰回复质量反而下降。举实际的例子你的技能在拉取数据后如果返回的结构是“本周日报-目标链接周食数据-目标链接结果汇总-目标表格下周建议-目标3 条建议”Agent 接下来就能聚焦在“怎么把这些信息组织成一篇好看的周报”上。而不是面对 2000 行原始数据无从下手。6. 常见的技能故障排查从“没触发”到“参数错乱”无论你用的是哪种实现路径技能在实际运行中难免出问题。我总结了四个在社群和工作中最高频的故障现象并给出完整的排查思路。我建议你在看到这里时不要只收藏试着搭一个自己的简单技能然后在运行中体会这些故障的成因——这比看十篇文章都有用。6.1 故障一明明说了触发词技能就是不启动这是最让人心态爆炸的问题之一。用户说“出周报”Agent 愣是回了一句“好的请问你想生成什么内容的周报”——这就说明 Agent 根本没有识别出你要启动技能。排查链路一般是这样的先看技能描述是否符合用户的表达习惯。如果你的技能描述是“生成周报文档”那用户说“出周报”时语义距离其实还不够近。你可以改成“当用户说周报、周总结、出周报、每周报告等表述时使用”。再看有没有优先级更高的其他技能或指令把这次触发拦截了。有些 Agent 平台允许设定全局指令比如“如果用户请求不明确必须追问澄清”——这个指令如果优先级比技能更高那技能永远启动不了因为每次都先被“追问澄清”给截胡了。最后看是不是技能被禁用了或权限范围受限。有些技能只在特定的 Agent 或特定的会话里生效你如果在配置技能时选择了“仅在工作台可用”然后在聊天窗口里触发自然就无效。6.2 故障二技能触发了但参数拿到的是乱码这种故障的表现是技能确实启动了但用起来完全不对比如你的report_month被填成了“今年4月份”这种中文字符串而你的执行逻辑只接受2025-04。问题大概率出在参数 schema 上你不是没有定义格式而是格式的描述不够“模型友好”。模型很聪明但它默认按最自然的表达来填如果你的 schema 里只写了type: string没有写pattern和提示示例模型大概率会按原文填进去。应对方法给每个参数都提供正则约束 示例。直接告诉模型“请把用户说的‘今年4月份’转成‘2025-04’再填入”这样抽取准确率会有明显提升。6.3 故障三技能内部某一步抛错整个流程中断这种问题在代码型技能里几乎每天都会遇到。你调用的接口超时了或者返回的数据格式变了技能直接崩溃用户只看到一个“执行失败”。排查时最忌讳的就是“看表面”。你第一反应应该去看日志找到具体是哪一步抛错。如果你的日志比较完善你应该能看到类似“调用数据源 API 超时5s 没有响应”这种记录。有了这个信息你可以决定是加超时重试还是换一个更稳定的数据接口。如果你用的是一个没有太多日志的现成平台确实会比较难排查因为你只能看到失败结果而看不到内部步骤。这种情况我建议你在技能设计阶段就加上“分段输出”每完成一个步骤就把{step: data_fetched, count: 20}这样的中间状态写到日志里。这样即使整体失败你也能定位到是哪一步出的问题。6.4 故障四技能结果不稳定同样的输入两次结果不一样这个现象在大模型驱动的 Agent 里太常见了。同样的技能、同样的参数、同一份数据跑两次出来的解读和预测完全不一样甚至有一次直接忽略了某个重点指标。大部分原因是温度参数temperature没有针对技能场景做调优。如果这个技能的目的是“生成严谨的分析报告”温度就应该调低一点如果目的是“头脑风暴写点子”温度可以高一点。你如果把所有技能都用一套温度配置那结果不稳定就是必然的。另一个原因是提示词里没有给足约束条件。你需要在生成分析的时候明确告诉模型必须基于数据说话数据中没有体现的内容不要臆测必须覆盖用户指定的重点指标如果数据波动超过阈值必须单独提示。这些约束条件就是“模型发挥空间”的护栏护栏多了随机性自然降下来。7. 技能的安全边界与行为审计意识技能这个东西本质上是把 Agent 的一部分行为“程序化”了。程序化是有好处但也有隐患——如果技能的执行路径、参数来源、工具权限没有做好管理它可能会成为一个难以监管的后门。我看到热搜里有“智能体行为审计是什么意思”这个问题这里我也顺便展开说几句因为它跟技能有直接关系。7.1 技能运行中你要盯紧的四个环节技能的安全问题主要集中在四个环节参数注入、工具权限、数据访问范围、输出内容合规。参数注入最典型的问题是用户通过输入故意构造恶意参数试图让技能执行预期之外的逻辑。比如你的技能有一个参数是filter_keyword用户传入了非常规值来操纵查询条件如果你的技能直接把参数拼进查询语句就可能导致查询范围被扩大或篡改。你需要在两个层面做防护入口处校验对参数进行类型、格式、枚举值检查和出口处限权即使参数被绕过校验底层工具或数据接口的权限也要能做到最小授权。工具权限要遵循最小可用原则技能执行过程中调用的工具只能拥有完成当前任务所需的最小权限。不要给技能配置一个“可以删除任意文件”的工具接口哪怕你觉得内部工具不会有人刻意去触发——真实世界里就是会有误操作和滥用。数据访问范围要限制在业务必需。技能能拉到的数据范围应该是“借助当前技能完成目标所需的最少数据”而不是“系统里所有数据”。这是我在做企业内部 Agent 时特别强调的一点因为内部工具一旦数据权限失控出的问题往往都是大问题。最后是输出内容合规。技能生成的文本、文档、报告要在出口做一次内容检查。要特别留意的是那些用户输入中的内容被原样带回到输出里的场景——你技能如果只是简单把用户话术拼进模板再返回那它就相当于一个“复读机”原本需要模型发挥的分寸就没有了。7.2 给技能做一次行为日志你会发现很多意外现在不少 Agent 平台都提供了日志功能但我发现很多人在使用的时候根本没看日志的习惯。这很可惜。我给自己的技能都加了行为日志每条日志记录四个字段触发时间、输入参数摘要、调用了哪些工具、返回结果状态。不用记太细但这四个字段组合起来就已经能回答很多问题了这个技能一天被触发了多少次评估真实使用频率哪些参数值是高频出现的进一步优化默认参数多少次调用以失败告终评估稳定性有没有在预期之外的场景被触发排查触发规则问题有一次我就是通过检查日志发现一个“生成周报”的技能在凌晨三点被人连着触发了十几次参数里全是乱码。排查后发现是某个测试脚本误调用了这个技能的 API如果把日志关了这个异常会一直默默消耗资源而不被发现。7.3 技能的安全配置清单这里我列一份检查清单每上线一个技能之前你可以拿它过一遍技能参数是否做了类型和格式校验技能能调用的工具是否严格限制了权限技能能访问的数据范围是否最小化技能输出是否经过了内容安全检查技能执行是否有完整日志记录技能在异常情况下是否会明确说“拒绝”而不是瞎尝试技能描述里是否写清了边界防止被误触发这些检查项看起来基础但真的都过一遍之后你会发现技能上线之后变“稳”了非常多。8. 技能进阶从单技能走向技能编排当你把单个技能做熟练之后下一步的进阶方向是技能编排——也就是把多个技能像拼积木一样串联起来完成一个更复杂的任务。拿“每月经营分析会材料”这个场景来说它就不是一个技能能搞定的。它需要数据简报技能生成核心指标、客户分析技能拆解客户结构变化、竞品动态技能收集公开信息并摘要、最后由一个汇报材料技能把前面所有产出合并成一份最终文档。这里的关键不是“在技能里写流程”而是“在 Agent 的调度层实现编排”。你在每个技能内部要做的是把它自己的那一步做扎实而不是试图把所有步骤都塞进一个技能里。8.1 技能编排的三种常见模式我列三个典型的编排模式大家可以根据场景套用顺序编排A 技能执行完把结果传给 B 技能B 执行完传给 C。适合流程固定的场景比如数据处理链路先清洗、再分析、再可视化。条件编排根据 A 技能的输出结果决定要不要执行 B 技能。比如数据简报技能发现有重大异常指标才触发深度分析技能如果没有异常直接输出即可。并行编排多个技能同时执行最后汇总结果。适合各技能之间相互独立、但共同服务于一个任务的场景比如同时并行获取销售数据、客户数据、竞品数据最后合并到一份报告里。8.2 技能编排落地的三个注意点一个是技能间的数据契约。技能 A 的输出格式必须能被技能 B 理解。最好的做法是定义一个统一的数据结构所有技能都按这个结构输出中间结果。另一个是失败传播策略。在顺序编排里如果 B 技能失败了你是要 A 技能重跑还是直接让人工介入我建议在编排层明确指定否则技能链条会无限重试既烧钱又无意义。还有一个是最终输出的整合节奏。不要让你的汇报技能等所有并行技能都跑完才开始取材而是让每个技能一产出中间结果就推送到一个共享区汇报技能按时间轴增量读取。这个机制搞得好整个编排链路性能会有一个很大的提升。9. 沿着这条路走技能的下一个形态我知道不少人看到这里已经开始琢磨“我要不要把一个完整的部门日报体系做成技能链”这种事了。我的态度是想清楚再做别为了做技能而做技能。技能不是上下游它本质上是习惯的抽象化。你先把那些真正高频、真正重复的动作识别出来然后把它们封装成一个个独立的、边界清晰的技能再逐步把几个技能编排成一条流程。这个过程不需要一蹴而就它应该是缓慢积累、迭代演进出来的。有一个我从实践中得到的经验可以作为你们的参考我在给团队做内部培训时要求每个人都先把自己一周内重复做过三次以上的操作写出来。然后我们筛选出其中逻辑闭环完整、耗时超过十分钟的事项评估是否有必要做成技能。最后真的做成技能的只有不到 40%。但就是这 40%把团队里大部分重复性劳动都消化掉了。所以你可以想想你日常的工作里有多少动作是每周都在重复的如果你把这些动作的数复、托付、整理、汇总都变成了“一句话启动”的技能你每天节省出来的时间可能比你想象中要多得多。技能这条路本质上是给 Agent 装上“肌肉记忆”。前几次用的时候你可能觉得不过如此但当你积累到二三十个顺手技能之后你会明显感到 Agent 从一个“每次都要重新调教的实习生”变成了“知道你要什么、按部就班去干的老搭档”。我自己在打磨技能的过程中最深的体会就一个不要追求一步到位的完美技能先让它跑起来然后在一次一次使用中迭代它的边界、它的参数、它的容错。技能的价值是长出来的而不是设计出来的。