一个 Agent 挂 30 个 Skill，会发生什么？从工具路由看配置税

给 Agent 增加一个 Skill，局部收益很容易看到：它多了一套流程、一个脚本或一份领域说明。连续加 30 次，系统收益却不一定线性增长。

原因不神秘。我们把 30 个局部正确的组件，放进了同一个路由、上下文和权限域里。复杂度没有消失，只是从"模型不会做"转移成"系统该选谁、带什么、允许做什么、怎样证明做完"。

所以本文讨论的"配置税"不是反对 Skill，更不是给数量设一条红线。30 个按需加载、边界清楚的 Skill，完全可能优于 5 个常驻且高度重叠的 Skill。

配置税的工程模型

可以先写一个不严谨但好用的式子：

ConfigurationTax
  = RoutingCost
  + ContextCost
  + PermissionCost
  + MaintenanceCost
  + VerificationCost

它们分别对应五种失败。

RoutingCost：候选越像，路由越难

工具路由不是简单的字符串匹配。用户说"查一下最近的 Agent 新闻"，可能同时命中网页搜索、新闻聚合、浏览器、RSS、站内搜索和深度研究。

如果这些工具描述没有说明信息范围、时效、返回格式和失败行为，模型只能用有限线索猜。工具数量不是唯一变量，描述的可区分性更关键。

8 月 9 日的一篇预印本分析了 138,133 个公开 SKILL.md 文件。研究报告称，91.8% 至少有一项被其自动检测器识别的缺陷，常见问题包括弱路由元数据、臃肿或不可执行的正文、资源组织不佳；在 20,000 个 Skill 的路由压力测试中，元数据合规的 Skill 更容易被检索。

这个结果有明显边界：公开仓库不代表生产系统，缺陷比例也依赖论文定义。但它说明 routing metadata 不是装饰，而是运行时接口。

ContextCost：工具说明位于循环的热路径

Agent 不是只请求模型一次。它可能计划、调用工具、读取结果、修正计划，再继续调用。放在上下文里的工具描述和重复指令，会在循环里持续产生开销。

OpenAI 关于 GPT-5.6 harness 的官方文章把这个问题称为 context bloat：更多工具、Skills、Plugins 和历史会增加成本、分散模型，并诱发不必要推理。它给出的方案是 deferred discovery，让集成和能力只在需要时 surface。

当前模型指南也建议只暴露任务相关工具。其内部 coding-agent 样本里，较精简的 prompt 配置让评测分数方向性提升约 10%--15%，token 降低 41%--66%；官方提醒必须在自己的 workload 上复验，不能当通用保证。

换句话说，工具目录不应该等于模型每轮都要读的菜单。

PermissionCost：一个入口承载了所有 blast radius

研究 Agent 需要读网页和写事实表，发布 Agent 需要使用平台登录态，财务 Agent 可能触达敏感账目。把它们挂到同一个 Agent，意味着一个错误路由可能跨过原本不该跨的边界。

权限设计应该跟着岗位，而不是跟着"用户已经登录"：

type Capability = {
  id: string
  role: "research" | "writing" | "design" | "publish"
  readScopes: string[]
  writeScopes: string[]
  approval: "none" | "before-write" | "before-external"
}

真正危险的通常不是 Agent 不会调用，而是它在错误的上下文里调用了一个本来合法的工具。

MaintenanceCost：Skill 是依赖，不是收藏品

Skill 可能引用脚本、模板、MCP、系统命令和第三方接口。依赖升级、路径改变、平台 DOM 调整，都可能让"昨天能用"变成"今天只跑了一半"。

维护至少需要这些元数据：

id: platform-publisher
version: 1.4.2
owner: content-ops
compatible_with: [desktop-agent-v3]
permissions: [platform-session, draft-read]
tests: [prefill-csdn, prefill-juejin, stop-on-captcha]
rollback_to: 1.4.1

没有 owner、version、tests 和 rollback，Skill 更像一段被复制来的临时代码。

VerificationCost：工具成功不等于任务成功

"写入成功"可能只是编辑器有内容，"发布成功"也可能只是点击事件被触发。Agent 的完成态应该由证据驱动：作品链接、管理记录、审核状态、文件校验或用户确认。

type DeliveryReceipt = {
  taskId: string
  artifact: string
  state: "draft" | "submitted" | "reviewing" | "published" | "needs_human"
  evidence?: string
  checkedAt: string
}

如果没有 receipt，失败就会变成一句很像成功的自然语言。

从巨型 Agent 改成岗位化能力层

一种更容易维护的结构是四层：

Goal Router
  ├─ Research Agent  -> research tools + fact contract
  ├─ Writing Agent   -> writing skills + style contract
  ├─ Design Agent    -> image tools + visual QA
  └─ Publish Agent   -> platform tools + delivery receipt

Router 先判断任务属于哪个岗位，再让岗位内部选择工具。跨岗位传递结构化产物，而不是把全部聊天记录和全部权限一起转交。

OpenAI 的 Agent 构建指南把 Agent 本身列为 orchestration tool，并明确建议：当所需工具数量上升时，考虑拆到多个 Agent。Anthropic 的金融 Agent 模板也按 Pitch Builder、Model Builder、KYC Screener 等岗位分别打包 Skills、Connectors 与 Subagents，同时配置 per-tool permissions 和人工批准。

这不是为了追求"多 Agent"这个名词，而是为了把三种边界对齐：上下文边界、权限边界和验收边界。

三个常见的错误重构

错误一：按工具品牌拆 Agent

"浏览器 Agent""表格 Agent""MCP Agent"不是岗位，只是实现方式。更稳定的边界来自业务产物，例如"竞品研究报告""平台稿件""发布回执"。

错误二：每个动作都拆成一个 Agent

拆得太细会产生新的交接税。标题改写和正文改写通常属于同一写作岗位；如果为了调用两个函数就建立两个 Agent，收益可能小于协议成本。

错误三：只做动态加载，不做验收

Tool search 能减少上下文，却不能自动保证工具正确、权限合理和结果可靠。动态发现解决"看见谁"，交付契约解决"做成什么"。两者不能替代。

一套最小改造顺序

如果已经有一个挂满工具的 Agent，可以按下面顺序改，不必推倒重来：

1. 记录一周真实任务，找出高频岗位，而不是凭功能列表分类；
2. 合并描述相近的工具，补充返回结构、错误行为和适用边界；
3. 把低频能力改为按需发现，主上下文只保留稳定入口；
4. 按岗位建立最小权限集合，外部写操作单独批准；
5. 为每个岗位准备 10--20 个代表性任务，升级后做回归；
6. 用结构化 receipt 定义完成态，不接受纯文字"已完成"。

优化时同时看成功率、完整性、调用错误、token、延迟和成本。只追求调用次数更少，可能把复杂度藏进一次更差的调用里。

我们在 Tipkay 里的取舍

这也是我们做 Tipkay 时选择岗位化 AI 员工的原因。我们没有把博客发布、视频制作、PPT、内容运营等能力全塞进一个默认工具箱，而是让每个岗位带自己的工作方法、Skill、MCP 和检查方式，需要协作时再把一个岗位作为另一个岗位的工具。

普通用户先使用官方维护的岗位，不需要从空白 Agent 开始研究路由和权限；有定制需求时，再复制岗位，加入业务资料、流程、Skill 与 MCP。目标不是让用户永远不能配置，而是把配置从"上岗前的必修课"变成"业务成熟后的可选升级"。

岗位化也不是银弹。拆分、版本和协作本身都有成本，官方流程也要持续适配平台变化。它只是把配置复杂度放到更适合维护的位置。

结语

Skill 让 Agent 获得经验，架构决定这些经验会不会互相打架。

真正该优化的不是安装数量，而是暴露策略、岗位边界、权限和验收。下一次给 Agent 增加能力时，先问一句：它应该成为这个岗位的常备工具，还是只在特定任务里按需出现？

这个问题，往往比"还能不能再装一个"更重要。

参考：OpenAI 企业使用研究、GPT-5.6 harness 技术文章、Model guidance、Agent 构建指南；Anthropic 金融 Agent 模板；预印本 arXiv:2608.08453。