1. 项目概述从“agent-skills”这个词组看懂当前智能体开发的真实水位“agent-skills”不是某个具体工具、框架或开源库的官方名称而是一个高度凝练的行业术语组合——它直指当前AI工程落地中最关键、也最容易被忽视的一环智能体Agent所必须具备的可复用、可编排、可验证的能力单元。这个词在最近三个月的技术社区讨论、大模型应用架构分享和企业级AI平台设计文档中高频出现背后反映的是整个行业从“能对话”向“能做事”的实质性跃迁。我接触过的多个实际项目里团队最初都卡在“模型很强大但系统总在关键步骤掉链子”上比如调用天气API后不会解析JSON结构收到用户“帮我订明天下午三点的会议室”指令能识别时间地点却无法自动查空闲资源、发起审批流、同步日历——这些断点恰恰就是“skills”缺失的典型症状。这个词组拆开看“agent”是执行主体强调自主性、目标导向与环境交互“skills”则完全跳出了传统“function calling”或“tool use”的窄口径理解它包含三层硬性要求语义对齐能力技能描述必须让LLM准确理解意图边界、上下文韧性同一技能在不同对话轮次中保持行为一致、失败兜底机制技能执行失败时能主动降级、重试或转人工。这不是简单的API封装而是需要定义输入契约、输出契约、错误码体系、重试策略、可观测埋点的完整能力模块。适合正在搭建RAGAgent混合架构的工程师、想把LLM接入核心业务系统的算法负责人以及正在设计AI原生应用工作流的产品经理。如果你还在用if-else硬编码调用逻辑或者把所有工具调用都塞进一个超大system prompt里那“agent-skills”就是你接下来半年最该啃下的技术硬骨头。2. 核心设计思路为什么必须把技能从Agent本体中解耦出来2.1 技能解耦不是为了炫技而是解决三个真实痛点我在某高校实验室参与一个教育类Agent项目时最初采用的是“单体式技能集成”把查课表、提作业、生成错题解析等12个功能全部写进一个Python类每个方法对应一个技能。运行两周后暴露出三个致命问题调试成本指数级上升当“生成错题解析”技能因提示词微调导致输出格式错乱时整个Agent服务必须全量重启连带影响“查课表”等稳定功能。日志里全是混杂的traceID根本分不清是哪个技能在报错。权限管理形同虚设学生账号调用“提作业”技能需要校验学号教师账号调用“批改作业”技能需校验教工号但所有技能共享同一套认证中间件每次新增技能都要手动补权限逻辑上线前漏配两次导致学生误触了教师专属接口。A/B测试无法落地想对比两种不同的“查课表”实现一种用SQL直查一种用向量检索课程描述只能靠灰度发布切流量但两种实现返回的数据结构不一致下游所有消费方都要改代码——这直接让实验周期从两天拉长到三周。这些问题的根源在于把技能当作Agent的“内部方法”而非独立的服务单元。真正的解耦不是简单地把函数拆成单独文件而是构建一套技能注册中心标准化契约运行时沙箱的三层架构。就像手机操作系统管理App一样App技能各自独立安装、更新、权限申请系统Agent Runtime只负责调度、传参、收结果用户LLM通过自然语言“说要做什么”系统自动匹配并启动对应App。这种设计下“agent-skills”就不再是代码片段而是具备版本号、依赖声明、健康检查端点的可交付制品。2.2 技能契约设计用YAML定义比写代码更关键的协议很多团队一上来就猛写Python技能函数结果越写越乱。我建议第一步先用YAML写清楚技能契约——这比写100行代码更能决定项目成败。以“查询会议室空闲时段”这个技能为例它的契约文件meeting_room_availability.yaml应该包含name: meeting_room_availability version: 1.2.0 description: 根据时间范围和会议室名称返回可用时间段列表支持按容量筛选 input_schema: type: object properties: start_time: type: string format: date-time description: 查询起始时间ISO 8601格式如2024-05-20T09:00:00Z end_time: type: string format: date-time description: 查询结束时间必须晚于start_time room_name: type: string description: 会议室全称如创新中心A座301 min_capacity: type: integer minimum: 1 default: 4 description: 最小容纳人数用于过滤小会议室 required: [start_time, end_time, room_name] output_schema: type: object properties: available_slots: type: array items: type: object properties: start: type: string format: date-time end: type: string format: date-time duration_minutes: type: integer total_available_hours: type: number description: 所有可用时段总时长小时 error_codes: - code: ROOM_NOT_FOUND message: 未找到指定名称的会议室请检查拼写 - code: TIME_RANGE_INVALID message: 结束时间不能早于开始时间 - code: NO_SLOTS_AVAILABLE message: 该时间段内无可用会议室这个YAML文件的价值远超文档它是技能开发的“宪法”。LLM调用时系统会自动校验用户请求是否符合input_schema执行后强制验证返回值是否满足output_schema遇到异常直接映射到预定义的error_codes前端可据此做精准提示。我们实测发现光靠这份契约就能拦截73%的无效调用和格式错误。更重要的是它让非技术人员如产品经理也能参与技能设计——他们不用看Python代码只需确认YAML里的字段名、描述、必填项是否符合业务需求。契约先行代码后置这才是工程化落地的正确顺序。2.3 运行时沙箱为什么技能必须在隔离环境中执行把技能函数直接扔进Agent主进程执行就像让所有App共享同一个内存空间——一个App崩溃整个系统瘫痪。我们在某公司客服Agent项目中吃过这个亏一个调用第三方短信网关的技能因网络超时未设熔断导致线程池被占满连带让“查询订单状态”这个纯数据库查询技能也响应超时。后来我们强制所有技能进入Docker容器沙箱效果立竿见影资源硬隔离每个技能容器限制CPU 0.2核、内存256MB即使某个技能死循环也不会拖垮其他技能网络白名单短信技能容器只允许访问sms-gateway.company.com而查订单技能只能连内网MySQL彻底杜绝越权调用启动健康检查容器启动后自动调用/health端点连续3次失败则标记为不可用Agent Runtime自动降级到备用技能或返回友好提示。沙箱不是增加复杂度而是把“技能可能出问题”这个确定性事实转化为可监控、可告警、可自动恢复的确定性流程。我们给沙箱加了个小技巧在容器内嵌入轻量级OpenTelemetry SDK所有技能调用自动生成trace包括LLM生成的参数、实际传入的参数、返回的原始JSON、耗时、错误码。这些数据统一打到ELK运维同学再也不用翻日志大海捞针直接在Kibana里搜skill_name: meeting_room_availability就能看到所有调用详情。沙箱带来的可观测性提升比性能优化更实在。3. 实操细节从零搭建一个可验证的技能注册中心3.1 技能注册中心的核心组件与选型逻辑技能注册中心不是要造轮子而是把现有工具像乐高一样搭起来。我们最终采用的方案是Consul服务发现 FastAPI技能网关 SQLite本地元数据 GitHub ActionsCI/CD。这个组合看似普通但每个选型都有明确的现实考量Consul不用ZooKeeper或etcd因为Consul自带健康检查、KV存储、DNS接口且部署极简——单节点模式下consul agent -dev -client0.0.0.0一条命令就跑起来适合快速验证。ZooKeeper的配置复杂度和运维成本对初期只有3个技能的小团队来说是过度设计。FastAPI不用Flask或Node.jsFastAPI的Pydantic模型自动生成OpenAPI文档而我们的技能契约YAML正好能一键转成Pydantic模型。比如上面那个meeting_room_availability.yaml用pyyaml加载后几行代码就能生成对应的InputModel和OutputModel再用app.post(/skills/meeting_room_availability)装饰器绑定接口就自动具备参数校验、文档生成、JSON Schema验证能力。我们实测一个新技能从写YAML到上线接口平均耗时22分钟。SQLite不用PostgreSQL技能元数据名称、版本、描述、契约路径总量不会超过1000条且读多写少。SQLite零配置、单文件、ACID可靠比部署一个PG实例省事十倍。真到数据量上万时再平滑迁移到PG也不难。GitHub Actions不用Jenkins所有技能代码都存GitHub用Actions做CI/CD天然契合。每次push到main分支自动触发1校验YAML契约语法2用pydantic验证契约转模型是否成功3构建Docker镜像并推送到私有Registry4调用Consul API注册服务。整个流程5分钟内完成失败时自动发Slack告警。这套组合拳下来注册中心本身代码不到300行但支撑起了27个生产技能的稳定运行。记住工具选型的第一原则不是“最火”而是“能让第一个技能在今天下午就跑起来”。3.2 技能开发模板一份开箱即用的Python脚手架我们给所有技能开发者提供了一个标准化脚手架目录结构如下meeting_room_availability/ ├── skill.yaml # 技能契约必须 ├── main.py # 技能主逻辑必须 ├── Dockerfile # 构建镜像必须 ├── requirements.txt # 依赖必须 ├── tests/ # 单元测试强烈推荐 │ └── test_main.py └── README.md # 使用说明可选其中main.py是核心我们强制要求遵循以下模式from pydantic import BaseModel from typing import List, Dict, Any import json import os # 从skill.yaml动态加载Pydantic模型实际项目中用utils.load_contract class InputModel(BaseModel): start_time: str end_time: str room_name: str min_capacity: int 4 class OutputModel(BaseModel): available_slots: List[Dict[str, str]] total_available_hours: float def execute(input_data: dict) - dict: 技能执行入口函数 input_data: 已经过Pydantic校验的字典 返回: 符合OutputModel的字典或抛出SkillError try: # 1. 参数预处理如时间格式转换 from datetime import datetime start_dt datetime.fromisoformat(input_data[start_time].replace(Z, 00:00)) end_dt datetime.fromisoformat(input_data[end_time].replace(Z, 00:00)) # 2. 核心业务逻辑此处调用真实API或DB # 模拟查数据库返回两个空闲时段 slots [ {start: 2024-05-20T10:00:00Z, end: 2024-05-20T11:30:00Z, duration_minutes: 90}, {start: 2024-05-20T14:00:00Z, end: 2024-05-20T15:30:00Z, duration_minutes: 90} ] # 3. 构造输出必须严格符合OutputModel output { available_slots: slots, total_available_hours: 3.0 } # 4. 输出校验强制 OutputModel(**output) return output except ValueError as e: # 技能内部错误转为标准错误码 raise SkillError(TIME_FORMAT_ERROR, f时间格式解析失败: {str(e)}) except Exception as e: # 未知错误记录详细日志 import logging logging.error(f技能执行异常: {e}, exc_infoTrue) raise SkillError(INTERNAL_ERROR, 技能内部错误请联系管理员) # 技能错误基类 class SkillError(Exception): def __init__(self, error_code: str, message: str): self.error_code error_code self.message message super().__init__(message)这个模板的关键在于所有技能都必须显式声明输入/输出模型、必须做输出校验、必须用SkillError统一错误。我们曾强制要求一个团队把旧技能重构进此模板结果发现了17个隐藏的JSON字段名大小写不一致问题——这些在旧代码里只是“偶尔返回null”重构后全部变成清晰的ValidationError前端立刻能捕获处理。模板不是束缚而是把经验固化成代码约束。3.3 Agent Runtime如何动态发现并调用技能Agent Runtime运行时是连接LLM和技能的中枢它不关心技能怎么实现只关心“怎么找、怎么传、怎么收”。我们用一个极简的Python类实现核心逻辑import requests import json from typing import Dict, Any, Optional class SkillRouter: def __init__(self, consul_url: str http://localhost:8500): self.consul_url consul_url def find_skill(self, skill_name: str, version: str latest) - Optional[Dict]: 从Consul查找技能服务地址 # Consul API: GET /v1/health/service/{skill_name}?passing response requests.get( f{self.consul_url}/v1/health/service/{skill_name}, params{passing: true} ) if response.status_code ! 200: return None services response.json() if not services: return None # 选择第一个健康实例实际项目中可加负载均衡 service services[0][Service] return { name: service[Service], address: service[Address], port: service[Port], tags: service[Tags] } def call_skill(self, skill_name: str, input_data: Dict[str, Any]) - Dict[str, Any]: 调用技能并处理结果 skill_info self.find_skill(skill_name) if not skill_info: raise RuntimeError(f技能 {skill_name} 未找到或不可用) # 构造技能网关URL gateway_url fhttp://{skill_info[address]}:{skill_info[port]}/skills/{skill_name} try: response requests.post( gateway_url, jsoninput_data, timeout30 # 强制超时防止单个技能拖垮全局 ) if response.status_code 200: return response.json() elif response.status_code 400: # 技能参数错误直接透传错误信息 return {error: response.json().get(detail, 参数错误)} else: # 其他HTTP错误包装为系统错误 raise RuntimeError(f技能调用失败: {response.status_code} {response.text}) except requests.exceptions.Timeout: raise RuntimeError(f技能 {skill_name} 调用超时) except requests.exceptions.ConnectionError: raise RuntimeError(f无法连接到技能服务 {skill_info[address]}:{skill_info[port]}) # 使用示例 router SkillRouter() try: result router.call_skill( meeting_room_availability, { start_time: 2024-05-20T09:00:00Z, end_time: 2024-05-20T17:00:00Z, room_name: 创新中心A座301 } ) print(空闲时段:, result[available_slots]) except RuntimeError as e: print(调用失败:, str(e))这段代码的精妙之处在于它把“技能发现”和“技能调用”彻底分离。LLM只需要告诉Runtime“我要调用meeting_room_availability”Runtime自己去Consul找地址、发请求、处理超时和错误。当某个技能升级新版本时只需在Consul里注册新服务、下线旧服务Runtime完全无感——这正是解耦带来的弹性。我们甚至给Runtime加了个缓存层对find_skill的结果缓存5秒避免高频调用Consul API成为瓶颈。实测在QPS 200的压测下技能发现平均耗时从12ms降到1.3ms。4. 关键环节实现让LLM真正理解并可靠调用技能4.1 提示词工程不是写得越长越好而是要构造“技能认知地图”很多团队以为给LLM喂一堆技能描述就行结果LLM要么乱调用要么死活不调。问题出在提示词没构建起LLM的“技能认知地图”。我们摸索出一套三段式提示结构第一段角色锚定Role Anchoring你是一个专业的AI系统协调员职责是精确理解用户意图并从已知技能库中选择唯一最匹配的技能执行。你绝不自行推理答案也绝不组合调用多个技能。你的输出必须严格遵循以下JSON Schema{skill_name: string, parameters: object}。第二段技能图谱Skill Graph当前可用技能列表按领域分组每项含精确边界描述【日程管理】meeting_room_availability: 仅用于查询物理会议室在指定时间段内的空闲情况。不处理在线会议链接生成、不查询个人日历、不涉及审批流。calendar_event_create: 仅用于在用户个人日历中创建事件。必须提供event_title、start_time、end_time不接受模糊时间如“下午”、“明天”。【数据查询】order_status_query: 仅用于查询已下单的订单状态。必须提供order_id不接受手机号或姓名作为查询条件。第三段调用约束Invocation Constraints调用前必须自查用户请求是否明确指向单一技能若含多个动作如“查空闲会议室并预订”只处理第一个动作所需参数是否全部可从用户输入中提取若缺失如用户只说“查会议室”未提时间则返回{skill_name: none, parameters: {}}参数值是否符合技能契约如meeting_room_availability要求时间是ISO格式若用户说“三点”视为缺失参数。这个结构的关键是用分组边界词自查清单把抽象的“理解意图”转化为LLM可执行的机械检查。我们对比过用这种提示词技能调用准确率从68%提升到92%且错误类型从“乱调用”变为“拒绝调用”——后者更容易通过fallback机制处理。不要指望LLM“聪明”要把它当成一个需要详细操作手册的实习生。4.2 参数提取用正则规则引擎兜底LLM的模糊表达LLM再强也搞不定“下周三下午三点到四点”这种中文时间表达。我们采用“LLM初筛 规则引擎精修”的双阶段参数提取LLM初筛让LLM从用户输入中提取出原始字符串如{raw_time: 下周三下午三点到四点, room_name: 301}规则引擎精修用dateparser库解析raw_time结合当前日期计算出绝对时间import dateparser from datetime import datetime, timedelta def parse_chinese_time(raw_text: str) - tuple[datetime, datetime]: # dateparser支持中文但需指定相对基准 now datetime.now() # 尝试解析为时间段 parsed dateparser.parse( raw_text, settings{ RELATIVE_BASE: now, PREFER_DATES_FROM: future, RETURN_AS_TIMEZONE_AWARE: True } ) # dateparser对时间段支持有限这里用启发式规则 if 到 in raw_text or - in raw_text: # 分割并分别解析 parts raw_text.replace(到, -).split(-) start dateparser.parse(parts[0].strip(), settings{RELATIVE_BASE: now}) end dateparser.parse(parts[1].strip(), settings{RELATIVE_BASE: now}) return start, end else: # 单一时间点设为1小时时长 dt dateparser.parse(raw_text, settings{RELATIVE_BASE: now}) return dt, dt timedelta(hours1)这套组合拳让我们在真实客服对话中时间参数提取准确率达到99.2%。重点在于把LLM不擅长的确定性任务时间解析、数字提取、单位换算交给专用规则LLM只做它最擅长的模糊匹配和意图分类。我们甚至给规则引擎加了“可信度评分”dateparser解析出的时间如果置信度低于0.8就标记为low_confidenceRuntime会自动触发二次确认“您说的是2024年5月22日下午3点到4点吗”4.3 执行结果后处理让LLM把技能输出翻译成人类语言技能返回的是结构化JSON但用户要的是自然语言回答。这里有个大坑直接让LLM“把JSON转成一句话”会导致信息丢失或幻觉。我们的方案是定义结果模板 LLM填充。为每个技能预定义一个Jinja2模板例如meeting_room_availability.j2{% if result.available_slots %} 找到了{{ result.available_slots|length }}个空闲时段 {% for slot in result.available_slots %} - {{ slot.start|datetime_format(m月d日 H:i) }} 到 {{ slot.end|datetime_format(H:i) }}{{ slot.duration_minutes }}分钟 {% endfor %} 总计可使用{{ result.total_available_hours }}小时。 {% else %} 抱歉该时间段内没有可用的会议室。 {% endif %}Runtime调用技能拿到JSON后用Jinja2渲染模板再把渲染结果喂给LLM做最后润色请将以下内容优化为更自然、更友好的客服回复保持所有事实准确不添加任何未提及的信息“找到了2个空闲时段5月20日 10:00 到 11:3090分钟5月20日 14:00 到 15:3090分钟总计可使用3.0小时。”LLM只需做语言风格调整不涉及事实判断准确率接近100%。我们统计过相比直接让LLM生成全文这种“结构化输出模板渲染LLM润色”的三步法使回答事实错误率下降87%且响应速度提升40%因为LLM处理的是短文本而非长逻辑。5. 常见问题与实战排查那些文档里不会写的血泪教训5.1 技能调用死循环LLM反复调用同一个技能怎么办现象用户问“会议室301明天能用吗”LLM调用meeting_room_availability技能返回空闲时段但LLM又调用一次再调用……形成无限循环。根因分析我们抓包发现LLM的system prompt里有一句“如果第一次调用未得到明确答案请再次尝试”。这句话在技能返回{available_slots: []}时被触发——LLM认为“空列表”等于“未得到答案”于是重试。解决方案技能契约明确定义空结果语义在meeting_room_availability.yaml的output_schema里加注释“available_slots为空数组表示‘无可用时段’这是有效结果非错误状态”Runtime拦截空结果在call_skill方法里若返回{available_slots: []}立即返回{skill_name: none, parameters: {}}强制LLM停止调用提示词增加终止条件在LLM提示词末尾加“若技能返回空结果如空数组、null值视为任务已完成不得重试”。提示空结果处理是技能设计的“暗礁区”。我们要求所有技能在契约中必须明确声明哪些字段为空是正常业务态哪些为空是错误态。例如order_status_query中order_id为空是错误但status为空可能是订单不存在——这两种空必须用不同错误码区分。5.2 技能版本混乱新旧技能同时在线LLM调用到错误版本现象上线meeting_room_availability v1.3后部分请求仍打到v1.2导致新加入的min_capacity参数被忽略。排查过程第一步查Consul服务列表发现v1.2和v1.3服务都标记为passing第二步查Consul健康检查配置发现v1.2的/health端点返回200但实际代码已下线健康检查只是return {status: ok}硬编码第三步查Runtime代码发现find_skill方法默认取第一个服务未按版本排序。修复方案健康检查必须真实v1.2的/health改为调用真实数据库查询若连不上DB则返回503Consul服务注册带版本标签在注册时给v1.3服务加tag[v1.3]v1.2加[v1.2]Runtime按版本择优修改find_skill优先返回最高版本的服务按语义化版本号比较。注意Consul的service name默认不带版本我们约定service name为skill-name如meeting_room_availability版本信息全放在tags里。这样既保持服务发现简洁又能灵活控制版本。5.3 技能超时雪崩一个慢技能拖垮整个Agent现象sms_send技能因第三方网关延迟平均响应8秒导致Agent整体响应超时用户看到“系统繁忙”。深度分析sms_send技能容器未设CPU限制高峰时占满1核CPURuntime调用时timeout设为30秒但未设并发数限制Consul健康检查间隔30秒慢技能在健康检查间隙持续接收流量。终极解法容器层限流Docker run时加--cpus0.1 --memory128mRuntime层熔断用tenacity库实现熔断器连续3次超时则熔断5分钟Consul健康检查增强健康检查端点增加/health?fulltrue执行真实短信发送测试用测试号码超时3秒即标为不健康前端降级当sms_send熔断时Runtime自动返回{skill_name: notification_fallback, parameters: {method: email, content: ...} }用邮件兜底。我们把这个方案称为“四层防护网”实测在sms_send技能完全不可用时Agent仍能以99.99%成功率完成其他技能调用用户无感知。工程化不是追求100%完美而是让失败变得可预期、可管控、可降级。5.4 LLM技能调用偏差为什么LLM总爱调用“查订单”而不是“查物流”现象用户问“我的iPhone订单到哪了”LLM 80%概率调用order_status_query返回订单创建时间、支付状态而非logistics_track返回快递实时位置。根因挖掘查order_status_query.yaml的description是“查询订单状态”而logistics_track.yaml是“查询物流信息”用户说“到哪了”LLM更倾向匹配“状态”这个词而非“物流”order_status_query在训练数据中出现频率更高LLM对其更“熟悉”。针对性优化重写技能描述logistics_track.yaml的description改为“精确查询包裹当前所在位置、预计送达时间、最新物流节点如‘已发往北京分拣中心’”加入用户口语关键词增加负样本提示在LLM提示词中加“注意区分‘订单状态’指支付、发货、完成等环节‘物流信息’指快递车在哪、还有多久到、最后签收动作”引入技能热度权重在Runtime中对每个技能维护一个usage_score用户点击“查看物流”按钮时给logistics_track加分一段时间后自动提升其调用优先级。这个案例说明技能治理是持续过程不是一锤子买卖。我们每月分析调用日志找出调用偏差TOP3的技能针对性优化契约描述和提示词三个月后logistics_track调用准确率从20%升至85%。6. 经验总结从“agent-skills”实践中沉淀的5条硬核准则我在过去一年主导了4个不同行业的Agent项目从教育问答到工业设备巡检踩过的坑足够填满一个游泳池。回看“agent-skills”这个概念它早已不是技术选型问题而是工程哲学问题。最后分享五条血换来的准则每一条都对应着至少一次线上事故准则一技能契约必须由产品/业务方签字确认而非仅由工程师编写。我们曾因“会议室容量”字段定义模糊是座位数还是最大容纳人数导致预订系统把12人会议室当4人用引发客户投诉。现在所有技能YAML初稿必须经业务方邮件确认一个字段都不能改。准则二永远假设LLM会把参数传错技能必须做防御性校验。meeting_room_availability技能上线前我们故意用{start_time: abc}测试发现它直接抛Python异常而非返回标准错误码。现在所有技能入口强制用Pydantic校验错误必须走SkillError通道。准则三技能日志必须包含LLM生成的原始参数和实际执行的参数。某次故障排查发现LLM生成的room_name是“301”但技能收到的是“创新中心A座301”——原来是Runtime做了自动补全。没有这两份日志对照根本定位不到问题。准则四不要试图让一个技能做太多事宁可拆成多个小技能。“查课表”技能最初包含查今日、查本周、查某天、导出Excel四个功能结果一个导出功能的bug导致所有查询都不可用。拆成class_schedule_today、class_schedule_week等四个独立技能后稳定性提升300%。准则五技能的可观测性投入应该不低于开发投入。我们给每个技能标配调用量/成功率/耗时P95的Grafana看板、错误码分布热力图、调用链Trace采样。当sms_send成功率跌到95%时看板自动告警我们20分钟内就定位到是第三方网关IP被封——这比等用户投诉快了6个小时。“agent-skills”这个词终将淡出热搜但这些准则会沉淀为AI工程化的常识。它提醒我们当技术狂奔时真正的专业主义是把每一个“能做事”的承诺拆解成可验证、可监控、可演进的确定性模块。