最近和很多团队聊 AI Agent，发现一个非常典型的现象：
这个功能不够，再加一个 Skill。
这个场景没覆盖，再补几个 Case。
这个工具不稳定，再接一个新的 API。
看起来很努力，实际上很危险。
因为以为是在增强 Agent，
其实是在把它做成一堆越来越脆弱的规则拼盘。
Skill 越多，不一定越强。
很多时候，Skill 越多，系统死得越快。
这篇文章想讨论的核心只有一句话：
在 Agent 设计里，真正决定系统上限的，不是堆了多少 Skill，而是有没有给模型建立清晰的决策边界。
一、为什么很多 Skill 一上来就走偏了
大多数团队设计 Skill 的方式，还是典型的软件工程思维：
- 先干什么
- 再干什么
- 如果失败怎么办
- 如果缺字段怎么办
- 如果超时怎么办
- 如果用户改口怎么办
这套思路在传统 Workflow 里是对的。
因为 Workflow 处理的是确定性问题：路径已知，分支有限，结果可枚举。
但 Agent 面对的不是流程问题，而是开放式决策问题。
它面对的是：
- 输入不完整
- 目标动态变化
- 上下文随时变化
- 外部工具状态不稳定
- 结果需要结合现实校验
这时候，如果还在用"把步骤拆细"的方式设计 Skill，最终就会把系统推向一种典型退化：
把策略写成路径，把边界写成流程，把开放问题做成死路。
这就是很多 Agent 最后看起来"功能很多"，但一遇到真实场景就崩的根本原因。
二、Agent 的核心不是"路径控制"，而是"边界控制"
人类写软件时，最擅长的是控制路径：
A 之后必须接 B，B 之后才能到 C，任何异常都要在 D 里处理。
但 Agent 不一样。
Agent 的价值恰恰在于：
它能在不确定条件下做出合理选择。
所以，Agent 的设计重点不是让它"严格执行某条路径"，而是给它一个足够清晰的边界空间：
- 什么时候必须触发某个 Skill
- 什么时候绝对不能触发
- 哪些数据必须外部校验
- 哪些结果必须交给人类确认
- 哪些情况要直接拒绝，不允许继续推理
- 哪些错误必须停机，而不是继续补救
换句话说：
Workflow 的资产是路径，Agent 的资产是边界。
如果把一个开放式 Agent 也当成 Workflow 来做，最终得到的不会是"聪明的系统"，而是一个"能跑的流程脚本"。
三、为什么"工具越多，能力越强"是一个危险幻觉
很多团队在给 Agent 加工具时，会陷入一个非常自然的误区：
"工具多一点，总归比少一点强吧。"
表面上看好像没错。
但在 Agent 系统里，工具数量增加，往往带来的不是能力线性提升，而是决策复杂度指数级上升。
1. 工具重叠会让模型不知道选谁
如果两个工具解决的是同一类问题，只是接口稍有不同，模型就会开始犹豫：
- 用哪个？
- 先查哪个？
- 哪个更可信？
- 哪个返回格式更适合继续推理？
这类选择困难，不是能力增强，而是决策噪声增加。
2. 工具越多，语义边界越模糊
很多系统不是没工具，而是工具太多之后，每个工具的责任都开始变得不清晰。
最后模型只知道"有个工具能查"，但不知道：
- 什么时候查
- 查什么
- 查到什么程度就够了
- 查不到怎么办
3. 工具集会把设计问题外包给模型
这是最隐蔽也最危险的一点。
很多团队以为自己在"增强 Agent"，实际上是在把本该由产品设计解决的问题，粗暴地丢给模型：
- 不确定的边界，让模型自己猜
- 有冲突的规则，让模型自己选
- 缺失的业务定义，让模型自己补
- 模糊的责任划分，让模型自己推断
最后会发现：
不是模型不会用工具，而是根本没把工具边界设计清楚。
四、真正值钱的不是补知识，而是建立现实约束
很多人在优化 Agent 时，会本能地想补知识：
- 更多文档
- 更多 Case
- 更多提示词
- 更多行业背景
- 更多 RAG 资料
但现实是：
大模型缺的通常不是知识量，而是现实约束。
因为模型天然擅长"生成合理答案"，
但不天然擅长"承认自己不知道"。
所以如果没有现实约束，模型就会倾向于：
- 用旧知识推断新问题
- 用局部信息补全缺失事实
- 用统计相关性代替事实校验
- 用貌似合理的答案覆盖真实的不确定性
这也是为什么很多看起来很强的 Agent，一进真实业务就出问题。
不是它"不懂"，而是它太容易在不确定时继续说下去。
因此，一个高质量 Skill 体系，必须包含现实约束机制：
- 哪些信息必须外部查询
- 哪些信息过期后不能信
- 哪些动作必须二次核验
- 哪些输出必须结构化验证
- 哪些情况下必须人工介入
- 哪些时候必须明确返回"不知道"
如果没有这些约束，做的不是 Agent，而是一个更会编造的自动化系统。
五、为什么"加规则"常常会把系统搞坏
很多团队在维护 Agent 时，最常见的补救动作就是：
"它刚刚出错了，那就在 prompt 里再加一条规则。"
这是一条非常典型的系统腐化路径。
第一阶段：规则补丁有效
刚开始，补一个 if-else，确实能修掉一个 bug。
团队会觉得系统被"控制住了"。
第二阶段：上下文被补丁挤爆
随着补丁越来越多，prompt 变长了，规则变复杂了，模型真正需要关注的核心信息反而被淹没了。
这时候你会发现，补的不是能力，而是噪声。
第三阶段：新旧规则互相打架
旧规则没删，新规则又叠上来。
结果就是：
- 规则冲突
- 行为不稳定
- 边界越来越模糊
- 一处修复，另一处破坏
第四阶段：系统进入反应式修补
团队开始每天盯线上错误，看到一个问题就塞一个新规则。
但这个时候，系统已经不是"有设计的 Agent"，而是"不断堆补丁的规则集合"。
所以，Skill 不是靠无限加规则变强的，而是靠边界收敛变稳的。
六、真正成熟的 Skill 设计，应该长什么样
如果你真的想把 Agent 做稳，Skill 设计需要从"流程描述"转向"决策定义"。
一个成熟的 Skill，不是告诉模型"怎么做"，而是告诉模型：
1. 它什么时候必须触发
也就是这个 Skill 的绝对触发条件是什么。
没有触发条件，模型就会乱用。
2. 它什么时候绝对不能触发
也就是排斥条件。
没有排斥条件，模型就会误用。
3. 它依赖哪些现实校验
比如必须查 API、必须查状态、必须对账、必须验证权限。
没有校验，模型就只能猜。
4. 它失败后怎么回退
失败以后是重试、降级、转人工，还是直接终止？
没有回退机制，系统会在错误里打转。
5. 它的完成标准是什么
什么叫成功？
是调用成功，还是业务结果达成，还是状态闭环？
没有完成标准，模型会"执行了动作"就以为任务完成。
这五件事，本质上是在给模型建立一套决策分水岭 。
而不是把它塞进一个越来越厚的流程脚本里。
七、少路径，多边界：开放式 Agent 的正确方向
如果把上面的内容收束成一句工程原则，就是：
开放式 Agent 的设计重点，不是尽可能多地写路径，而是尽可能清晰地定义边界。
这意味着你在设计 Skill、工具和流程时，应该优先做下面几件事：
- 删除重复工具，而不是继续加工具
- 合并语义重叠的能力，而不是拆成更多入口
- 明确外部校验点，而不是把判断留给模型猜
- 设置人工接管条件，而不是期待模型永远正确
- 用最小完备工具集覆盖关键任务，而不是追求"全家桶"
这也是为什么很多真正成熟的 Agent 系统，表面上看没有那么"炫"，但实际更稳。
因为它们不是靠复杂度赢的，而是靠边界设计赢的。
结语
我们对 Skill 的误解，往往来自一个根深蒂固的软件工程习惯：
总觉得把东西拆细、补全、补满，系统就会更强。
但在 AI 时代，尤其是在 Agent 场景里，真正决定系统上限的，不是堆了多少工具、写了多少规则、设计了多少流程，而是有没有帮模型建立一套清晰的现实边界。
- Workflow 需要路径
- Agent 需要边界
- 工具越多，不代表能力越强
- Skill 越多，不代表系统越稳
- 最强的系统，不是最复杂的系统，而是最可控的系统
所以，真正要做的不是"把 Skill 写得更多"，而是把它写得更准。
不是把路径铺得更长，而是把边界画得更清楚。
边界越清，系统越稳。