从 “软逻辑编排” 到 “硬能力调度”，重构 AI Agent 的技能执行架构

关于 BIDS 理论

BIDS（Binary-cured Intelligent Skills Dispatching System，二进制固化型智能技能调度系统）是一套彻底解决 AI Agent 技能落地痛点的工程化架构理论。它将高频、标准化的业务能力从 “大模型动态生成的软逻辑” 中剥离，预编译为符合统一接口规范的独立二进制程序，再由专属调度系统统一管理、按需分配、隔离执行，实现「LLM 语义路由 + 二进制固化执行」的分层协作模式，用确定性工程代码替代大模型推理的不确定性，同时大幅降低长期调用成本。

核心观点摘要

给技术决策者和开发者的关键结论：

当前 AI Agent 行业的主流技能方案（Prompt 描述 + Function Calling/CodeAct 编排），本质是「用大模型的动态推理能力弥补工程标准化的缺失」，导致三大无解痛点：执行效果不可控、长期调用成本高、业务逻辑迭代难。

BIDS 理论给出的落地方案是：

1.技能形态重构：将业务级 Skill（比如查询订单、触发工单、校验用户权限）从 “Prompt 文本描述” 转化为符合通用接口标准的二进制可执行程序，固化所有业务逻辑、分支判断、异常处理流程；

2.职责分层解耦：大模型不再负责 “怎么执行技能”，仅保留 “理解用户意图、匹配技能 ID、标准化参数校验” 的语义路由能力；

3.系统级调度管控：搭建配套的调度底层，统一负责技能的版本管理、灰度下发、资源隔离、超时控制、可观测性上报，将零散的二进制 Skill 整合成稳定、可扩展的企业级能力池。

BIDS 的核心价值不在于二进制技能本身，而在于「标准化能力 + 系统化调度」的完整工程闭环—— 它不是对现有 Skill 方案的微优化，而是从架构层面对 AI Agent 执行端的重新定义，完美适配企业级大规模落地的核心需求。

1. 背景：AI Agent 技能的 “不可能三角”

本章同时面向技术决策者和开发者，梳理行业落地的通用痛点

随着 AI Agent 从 Demo 验证走向生产级落地，行业主流技能方案的底层缺陷彻底暴露。无论是早期的「Prompt+Function Calling」模式，还是进阶的 CodeAct 范式，都无法同时满足执行稳定、调用低成本、业务可迭代三大核心要求，陷入了无解的 “不可能三角” 困境。

1.1 传统 Skill 的三大致命痛点

我们以电商场景下的「查询用户订单」技能为例，具象化说明落地痛点：

痛点一：执行效果不可控，完全依赖模型推理稳定性

传统 Skill 的逻辑步骤全部由 Prompt 描述，大模型需要实时理解技能功能、组装入参、编排执行流程。即使对入参格式做了严格的 JSON Schema 约束，模型依然可能在复杂上下文、多轮对话、高并发场景下 “逻辑漂移”：比如明明传递了合法的order_id参数，模型却在实际调用时遗漏字段；或者将用户输入的特殊字符错误转义，导致后端接口报错；更有甚者，在多技能串联的复杂任务中，模型会随机调整技能执行顺序，最终返回脏数据或直接执行失败。

这类问题的排查成本极高，复现率极低， same input 无法保证 same output，在涉及资金、用户隐私的高风险场景中，完全无法满足生产级的安全稳定要求。

痛点二：重复调用成本高，Token 开销呈线性膨胀

传统 Skill 的工作流中，所有技能的描述文档、参数定义、使用说明必须每次都塞进大模型的上下文窗口，否则模型无法正确调用。在高频重复调用、多技能串联、长周期任务场景中，上下文长度会随着轮次快速膨胀，直接推高两个核心成本：

•直接成本：大模型 API 的 Token 调用成本，部分企业的单 Agent 月均 Token 开销可达数万元；

•隐性成本：上下文越长，模型的推理时延越高，核心业务的用户体验越差，高并发场景下还会触发流量瓶颈。

即使采用 CodeAct 这类进阶方案，让模型生成代码批量执行多步操作，也只是减少了部分轮次开销，代码逻辑依然需要模型实时生成，无法从根源上降低 Token 成本。

痛点三：业务逻辑迭代难，技能与 Prompt 强耦合

传统 Skill 的逻辑载体是 Prompt 文本描述，没有独立的工程化形态，导致迭代维护成本极高：

•技能逻辑与 Agent 的 Prompt 上下文、模型的推理逻辑深度绑定，修改一个业务分支逻辑（比如给订单查询增加 “仅展示近一年订单” 的过滤条件），需要同步更新所有关联的 Prompt、入参校验规则、甚至模型的 few-shot 样例；

•技能无法独立版本迭代，不能灰度发布，线上出现兼容问题只能全量回滚，风险极高；

•技能的执行效果完全依赖模型的理解能力，没有统一的离线测试标准，无法提前预验证线上表现，只能让用户真实流量来验证结果。

1.2 现有方案的局限性

目前行业内的主流优化方案，都只是在 “不可能三角” 中做取舍，无法同时破解三大痛点：

•MCP（Model Context Protocol） ：仅统一了技能的接入协议，不规定技能的具体实现形态 —— 技能可以是常驻服务、脚本、二进制程序，它只定义调用规范，没有从执行层固化逻辑，依然无法解决模型编造参数、执行顺序漂移的问题；

•Anthropic Skills 体系：采用「文本描述 + 可执行程序」的混合模式，没有彻底抛弃软 Skill，依然需要将技能说明塞进上下文，无法从根源上降低 Token 开销，也不能保证执行逻辑的完全固化；

•CodeAct 范式：让模型实时生成代码代替函数调用，虽然减少了部分多轮 Token 开销，但代码逻辑依然由模型动态生成，存在代码注入、逻辑漂移的风险，代码执行环境的隔离成本也更高。

2. BIDS 理论架构：分层协作的确定性执行模型

本章面向技术决策者和开发者，拆解核心设计与工作逻辑

BIDS 的核心设计思路是分层解耦：将 AI Agent 的 “语义理解层” 和 “业务执行层” 彻底拆分，把大模型不擅长的固定逻辑编排、参数校验、异常处理、资源隔离等工程问题，下沉到二进制可执行文件层用代码固化；大模型只负责做人类擅长的意图理解和技能匹配，不参与具体业务逻辑的执行，用工程化的确定性覆盖模型推理的不确定性。

2.1 核心概念定义

BIDS 架构由两个核心层级构成，下层为上层提供标准化能力，上层负责将能力精准触达业务场景。

2.1.1 二进制固化技能（Binary-cured Skill）

BIDS 架构的标准化执行单元，是将单一业务能力的所有逻辑（主流程、分支判断、参数校验、异常兜底）编译成的独立可执行文件，其核心特征为：

•语言无关，形态统一：采用 Go/Rust/C++/Python 等任意语言开发，最终编译为单一二进制可执行文件（ELF/EXE/Mach-O/Wasm），无需依赖目标机器的语言运行时；

•逻辑完全固化：所有业务逻辑、判断分支、重试策略都提前写死在编译产物中，执行过程中不需要大模型的额外指令辅助；

•标准化接口约束：强制实现统一的调用协议，保证调度系统与技能的对接无适配成本，后文将详细阐述接口规范。

2.1.2 智能调度系统（Dispatching System）

BIDS 架构的核心管理中枢，是对接上层 Agent、管理所有二进制技能、编排完整业务流程的后端服务，核心职责包括：

•二进制技能的仓库管理、版本控制、灰度下发；

•接收 Agent 的技能调用请求，完成参数校验、权限拦截、流量路由；

•二进制进程的资源隔离、超时控制、挂起销毁、日志收集；

•串联多个二进制技能，完成复杂长任务的流程编排；

•执行链路的指标上报、异常告警、全链路可观测性。

注意：BIDS 架构的核心壁垒不是二进制技能本身，而是这套调度系统的标准化管理能力 —— 它将零散的二进制技能整合成了稳定、可复用、企业级的能力池。

2.2 标准化接口规范（核心设计）

为了彻底消除适配成本，让二进制技能实现 “一次编译、到处调度”，BIDS 强制所有技能实现双协议标准化接口，覆盖单机与分布式两种部署场景。

2.2.1 本地 IPC 协议（单机部署场景）

适配单机器上的轻量级调度需求，采用进程间通信 + 标准输入输出传递参数，满足简单、低延迟的调用要求：

•调用方式：通过命令行参数传递标准化 JSON 入参，格式为./${skill_name} --version=${skill_version} --input='{"trace_id":"xxx","params":{...}}'；

•返回规范：统一向标准输出打印结构化 JSON 结果，包含业务数据、执行耗时、链路追踪 ID；

•错误规范：强制使用 Linux 标准退出码，不同错误类型对应不同退出码（如参数非法返回 64、权限不足返回 77、执行超时返回 124），便于调度系统快速定位异常原因；

•资源约束：二进制程序必须自动读取调度系统下发的资源限制（CPU、内存、执行时长），超出资源限制时主动终止进程并上报错误。

2.2.2 内置 gRPC/HTTP 协议（分布式部署场景）

适配跨机器、跨服务的企业级调度需求，二进制程序启动时自动监听本地端口，提供符合统一规范的 RPC 接口，便于集群化调度管理：

•通用请求协议：采用 Protobuf/JSON 定义通用请求结构，包含技能版本、链路追踪 ID、业务参数、调用方凭证；

•通用响应协议：统一返回状态码、业务数据、错误信息、执行耗时、链路追踪 ID；

•健康检查规范：内置/health接口，返回技能版本、运行状态、资源使用情况，便于调度系统实时感知技能存活状态；

•元数据上报规范：内置/metadata接口，返回技能的功能描述、入参结构、使用样例，便于调度系统自动生成技能路由规则。

2.3 整体工作流

BIDS 架构的完整工作流分为 6 步，严格遵循 “语义路由、固化执行、标准化回传” 的核心原则，具体流程为：

1.意图理解：用户向 AI Agent 发送自然语言指令，Agent 通过大模型理解用户的核心业务目标；

2.技能路由：Agent 调用调度系统的技能列表接口，获取所有技能的极简元数据（功能描述、入参结构），由大模型根据用户意图匹配出指定技能 ID，生成标准化的入参；

3.技能调用：Agent 向调度系统发起技能调用请求，附带技能 ID、版本号、标准化业务参数；

4.进程调度：调度系统校验调用权限，根据请求方的环境、技能版本规则，从本地缓存或远程技能仓库拉取对应版本的二进制程序，启动隔离化进程；

5.固化执行：二进制程序接收标准化入参，完成参数校验、业务逻辑执行、下游服务调用，将结果写入标准输出；

6.结果回传：调度系统捕获进程的标准输出和执行日志，将结构化结果返回给 Agent，由 Agent 整理为自然语言报文返回给用户。

核心优化点：整个技能执行过程中，大模型仅参与第 2 步的意图匹配，不参与任何业务逻辑的编排；技能的描述文档不会被塞进上下文，不会造成 Token 开销膨胀。

3. BIDS 的核心价值

本节同时面向技术决策者和开发者，区分业务价值与技术价值

3.1 给企业 / 技术决策者的业务价值

价值一：彻底解决执行不确定性，提升业务稳定性

技能逻辑被编译为二进制可执行文件后，所有分支判断、异常处理逻辑被完全固化，不会受模型推理、上下文环境、并发流量的影响，相同入参永远返回一致的结果，执行稳定性可达 99.99%，完全满足交易、数据查询等企业级核心场景的安全要求。

价值二：大幅降低长期 Token 成本，提升业务可扩展性

BIDS 架构下，Agent 无需在上下文窗口中塞入完整的技能描述文档，仅需要传递技能 ID、版本号和结构化业务参数，单次调用的 Token 开销可降低 90% 以上。在高频调用、长周期任务、高并发场景下，Token 成本的下降幅度会随着调用频次线性放大，直接降低企业的长期模型 API 采购费用。

价值三：技能独立迭代，企业级交付风险可控

二进制技能拥有独立的版本号、变更日志、测试体系，业务逻辑迭代时只需重新编译二进制，通过调度系统灰度下发、流量切换，无需修改上层 Agent 的 Prompt 和路由逻辑；可以轻松实现金丝雀发布、版本回滚，新逻辑仅面向少量用户开放，验证无误后再全量推广，大幅降低业务迭代的线上风险。

价值四：天然满足合规审计要求，提升数据安全性

二进制技能的执行过程封闭可审计，所有调用请求、执行日志、资源占用、下游服务交互记录都被调度系统完整采集，便于合规审计；不会出现模型幻觉编造越权参数、恶意读取隐私数据的场景，技能的执行权限可被调度系统严格管控，满足金融、医疗等对数据安全要求极高的行业合规标准。

3.2 给开发者的技术价值

价值一：架构分层解耦，并行开发提升效率

业务开发团队无需再关注大模型的 Prompt 工程、上下文优化、模型兼容问题，算法团队也无需参与业务技能的逻辑迭代，双方通过标准化接口并行开发，只需要提前约定好入参结构、返回格式、错误码规则，互不影响。

价值二：离线预验证简单可靠，线上故障概率大幅降低

二进制技能可以脱离 Agent、脱离大模型、脱离调度系统，直接通过命令行调用做离线测试，用自动化测试工具覆盖所有业务分支逻辑，提前验证执行结果，不会出现 “本地测试正常，线上因为模型推理异常失效” 的情况。

价值三：多语言、跨平台兼容，复用现有技术资产

二进制技能的开发语言不受任何限制，可以复用企业现有 Java/Go/Python 的业务代码资产，不需要再学习模型微调、Prompt 工程、模型适配技术，开发完成后编译为对应平台的二进制文件即可直接部署。

价值四：适配主流开源生态，迁移改造量低

BIDS 的接口设计与行业现有主流协议完全兼容：调度层可以直接复用 MCP、Anthropic Skills 的现有适配逻辑，将二进制技能作为标准工具接入；上层 Agent 可以复用 MCP、Anthropic Skills 的客户端 SDK，无需重新开发调用逻辑，现有 Agent 框架的改造量极低。

4. 落地实操指南

本节面向开发者，给出快速落地的技术路径，适配公众号的代码阅读场景

BIDS 架构的落地遵循「由简入繁、逐步迁移、先固化再优化」的原则，开发者可以从现有技能体系中选取高频、高风险、逻辑固定的技能开始迁移，逐步用二进制技能替代传统软 Skill，快速验证效果。

4.1 技能开发打包规范

4.1.1 开发语言选型

优先选用可编译为跨平台单一二进制、自带资源管理能力的语言，降低打包和运维成本；也可以根据现有技术栈直接选择适配语言。

4.1.2 强制开发约束

为了保证二进制技能被调度系统正确管控，所有技能开发时必须实现以下三个核心能力，接入调度系统时才能通过校验：

1.标准化参数校验：技能内部内置入参的 JSON Schema 校验规则，启动时加载本地的规则文件，接收到入参后优先执行校验，非法参数直接返回标准错误码，不执行业务逻辑；

2.资源限额适配：技能启动时读取命令行参数或环境变量中的资源限制（如--cpu-quota=0.5、--memory-quota=100Mi），主动限制自身的资源占用，超出限制时主动终止进程；

3.日志链路标准化：日志内容统一采用 JSON 格式，包含链路追踪 ID、技能版本、入参摘要、执行耗时，日志级别严格按照规范划分，便于调度系统采集后串联全链路执行逻辑。

4.1.3 技能交付物

每个二进制技能的交付物必须包含以下 4 项，才能接入调度系统的技能仓库：

•可执行二进制文件：文件名符合${skill_name}-${version}-${os}-${arch}命名规范；

•技能元数据文件：JSON 格式，包含技能名称、版本、功能描述、入参结构、返回值格式、错误码列表；

•离线测试用例包：包含正常、异常、边界场景下的测试入参和预期结果，便于自动化验证；

•校验和文件：用于调度系统校验二进制文件的完整性和安全性，防止被恶意篡改。

4.2 调度系统选型与部署

调度系统是 BIDS 架构的核心管理中枢，负责对接上层 Agent、管理二进制技能、编排业务流程，企业可以根据自身规模和技术栈选择适配方案。

4.3 迁移步骤（从传统 Skill 迁移至 BIDS）

建议从现有技能体系中选取高频调用、逻辑固定、有离线自动化测试用例的技能开始迁移，逐步替代传统软 Skill，分步验证效果，降低迁移风险。

步骤一：技能拆分与固化

从现有传统 Skill 中剥离出核心业务逻辑，将依赖的下游 API、数据库调用、中间件交互逻辑封装为独立方法，补充实现标准化接口、参数校验、资源限制、日志链路等强制能力，编译为二进制文件，完成离线测试，保证单文件执行结果符合预期。

步骤二：接入调度系统

将二进制技能和元数据文件上传到调度系统的技能仓库，配置技能的版本路由规则、调用权限、资源配额、流量权重，在调度系统中验证技能的远程调用、资源隔离、异常返回是否符合预期。

步骤三：适配上层 Agent

在 Agent 层增加 BIDS 调度系统的客户端 SDK，将原来的「模型生成技能入参」逻辑，修改为「模型匹配技能 ID + 生成标准化入参」逻辑，调用调度系统的技能执行接口，接收结构化结果，兼容原来的返回格式，保证对上层业务无感知。

步骤四：灰度流量切换

在 Agent 层配置流量切分规则，将部分灰度流量导向新的二进制技能，剩余流量继续走原来的传统 Skill，对比双方的执行结果、耗时、资源占用，验证无误后逐步放大流量比例，直到完全替代传统 Skill。

步骤五：下线传统 Skill

监控二进制技能的线上稳定性、资源占用、错误率等指标，确认无异常后，从 Agent 的 Prompt 中移除对应传统 Skill 的描述文档，下线传统 Skill 的相关代码，完成迁移。

5. 适用场景与边界

本节用于建立理论的客观可信度，避免过度宣传，适配技术受众的理性认知

BIDS 架构不是万能解药，它有明确的适用边界，适配固定逻辑的业务场景，不适合无固定逻辑的开放场景，这也是它能保证执行确定性的前提。

5.1 高度适配场景

符合以下特征的技能，迁移到 BIDS 架构后的价值最为明显：

•高频调用场景：技能每天被调用数百次甚至数千次，降低单次 Token 开销后的成本收益最明显；

•逻辑固定的业务场景：技能的业务分支逻辑、参数校验规则长期稳定，不会频繁变更；

•高风险场景：技能涉及资金操作、用户隐私数据、高权限操作，对执行稳定性、合规审计性要求极高；

•多技能串联的复杂任务场景：技能需要被多个不同 Agent 调用，需要统一管理版本、编排流程。

典型的适配场景包括：电商场景下的订单查询、物流状态更新；企业 OA 场景下的工单创建、审批流触发；金融场景下的用户资产校验、流水记录查询；运维场景下的机器上线、日志采集。

5.2 不适配场景

符合以下特征的技能，无法通过编译固化逻辑实现，不适合采用 BIDS 架构，建议继续使用传统软 Skill 或 CodeAct 方案：

•一次性使用的极简技能：逻辑简单、调用频次低，打包、部署二进制的工程成本超过 Token 节约的收益；

•开放性、探索性任务：无固定流程的操作，比如根据用户的自由创意思路生成报告、对上传的文档做自由式分析、无固定条件的数据查询；

•逻辑频繁迭代的初创业务：业务分支逻辑、参数校验规则每周甚至每天都在变更，二进制的编译、灰度、回滚成本较高。

6. 结语与共建倡议

AI Agent 的行业落地，正在经历从Prompt 驱动的软逻辑向工程化固化的硬能力演进的必然过程：早期依靠大模型的动态推理快速验证业务场景，大规模落地后，一定会回归到用工程化的标准性解决稳定性、成本、迭代效率这些真实业务问题。

BIDS 架构的核心思路，本质是复用后端成熟的「服务化、标准化、版本化」思想重构 Agent 的执行端：将 Skill 从单纯的 “模型调用的工具文档”，转化为像 “Linux 命令” 一样的标准化可执行程序，既保留了 Agent 语义理解的灵活性，又用工程化手段解决了模型推理的固有缺陷。

参考文献

1.kubiyabot/skill 官方文档：《Why not MCP? Why skill binary?》

2.MoonBit Skills Marketplace 官方文档：《Skills: The Universal Tooling Format for AI Agents》

3.SkVM 官方论文：《SkVM: A Virtual Machine for Secure, Portable, and Efficient AI Agent Skills》

4.Anthropic 官方技能白皮书：《Anthropic Skills and Tooling Guide》

5.MCP 官方规范文档：《Model Context Protocol Specification》

6.CodeAct 官方论文：《CodeAct: Code as Actions for LLM Agents》

关于作者

Agent指挥部：由一线 AI Agent 架构师、资深后端开发工程师组成，长期专注于 AI Agent 的工程化落地实践，先后参与过多个企业级 Agent 平台的从零到一搭建，在生产级 Skill 的优化方向上有丰富的一线落地经验和技术沉淀。

该理论的提出，源于我们在企业级 AI Agent 落地过程中，对传统 Skill 的无解痛点的真实感悟 —— 在先后尝试了 Function Calling、MCP、CodeAct 等主流方案后，我们最终选择了 “二进制固化技能 + 系统化调度” 的工程化方向，将工程标准性与模型推理的确定性优势结合，是平衡业务灵活性和技术稳定性的最优架构选择。