1. 从“自动技能”到“自动策略”：一个被混淆的核心概念
大多数人第一次听到“智能体技能”这个词，脑子里浮现的画面大概是：一个机器人学会了拧螺丝、倒水、叠衣服，或者一个软件Agent学会了调用某个API、填写某张表单。这种理解本身没错，但它只停留在“技能”层面——也就是“会做某个具体动作”。而真正让物理世界里的智能体变得有用的，不是它会不会做某个动作，而是它能不能在环境变化、任务切换、约束冲突的情况下，自己决定“现在该做什么、先做什么、做到什么程度”。
这就是“自动策略”和“自动技能”的分水岭。
我最初接触这个概念的时候，也走过弯路。当时我在做一个仓储场景的机械臂调度实验，花了很多时间让机械臂学会抓取不同形状的包裹——圆柱的、方形的、软包的，每种都单独训练了一套抓取策略。结果上线测试时发现，机械臂确实“会抓”每一种包裹，但它不知道什么时候该抓哪个、抓完放哪里、遇到传送带堵塞该怎么调整顺序。换句话说，它有一堆技能，但没有策略。后来我们把问题重新定义：不再追求“学会更多抓取动作”，而是构建一个策略层，让智能体根据当前任务队列、工位占用情况、包裹优先级，动态选择调用哪个技能、以什么参数调用、失败后如何回退。效果立刻不一样了。
这个经历让我意识到，“自动策略”才是物理世界智能体的真正瓶颈。技能可以离线训练、可以复用、可以模块化，但策略必须在运行时根据实时状态做决策。而“编译型智能体技能”这个说法，恰恰是在强调：技能不应该是一堆散装的模型文件，而应该像编译后的程序一样，有明确的输入输出契约、有可组合的接口、有可验证的执行边界。
1.1 为什么物理世界比数字世界更依赖策略
数字世界里的Agent，比如一个网页操作助手，它的容错空间很大。点错了按钮可以撤销，页面加载慢了可以重试，最坏情况无非是任务失败，不会造成物理损伤。但物理世界完全不同。一个机械臂抓取失败可能意味着物料掉落、设备碰撞、产线停线；一个移动机器人路径规划失误可能意味着撞到人或者卡在通道里。物理世界的状态不可逆、代价高、约束硬。
这就决定了物理世界的智能体不能只靠“技能堆叠”来解决问题。你不可能为每一种可能的场景都预训练一个技能，因为物理世界的长尾场景是无穷的。真正可行的路径是：把技能编译成有明确语义的模块，然后用一个策略层在运行时动态编排这些模块。策略层负责“做什么、什么时候做、做到什么程度”，技能层负责“怎么做”。
这个分工听起来简单，但实操中很容易混淆。我见过不少团队把策略逻辑硬编码在技能里面，比如在抓取技能里写“如果传送带速度大于X就降低抓取力度”，结果就是技能越来越臃肿，策略越来越分散，最后没人能说清楚整个系统的决策逻辑。正确的做法是让技能保持“纯粹”——只负责在给定参数下执行动作，所有条件判断、优先级排序、失败回退都交给策略层。
1.2 编译型技能与传统技能模块的本质区别
传统技能模块往往是“黑盒”的：你给它一个输入，它输出一个动作，但你不清楚它在什么条件下可靠、什么条件下会失败、失败后应该怎么恢复。编译型技能的核心区别在于，它在“编译”阶段就明确了四件事：
- 前置条件：技能在什么状态下可以被调用，比如“夹爪空闲、目标物体在视野内、距离小于0.8米”。
- 后置条件：技能执行成功后世界状态应该变成什么样，比如“物体被夹持、夹爪闭合、物体离开传送带”。
- 失败模式：技能可能以哪些方式失败，每种失败对应什么错误码，比如“抓空”“滑脱”“碰撞”“超时”。
- 恢复接口：失败后策略层可以调用什么恢复动作，比如“重新定位”“释放夹爪”“请求人工干预”。
这四件事一旦明确，技能就不再是一个孤立的模型，而是一个可以被策略层可靠编排的“指令”。策略层不需要知道抓取模型内部有多少层卷积，只需要知道“调用抓取技能需要满足什么条件、成功后会得到什么、失败后有哪些选项”。这才是“编译型”的真正含义——把技能从“模型”变成“契约”。
2. EDGE SKILLGUARD：策略层与技能层之间的安全边界
在物理世界里做智能体，最怕的不是技能不够强，而是策略层在错误的时间调用了错误的技能，或者技能在边界条件下产生了不可预期的行为。EDGE SKILLGUARD 这个概念，本质上是在策略层和技能层之间加了一道“守卫”——它不负责决策，也不负责执行，而是负责在每次技能调用前后做检查、做约束、做兜底。
我把它理解成一个“编译器的类型检查器”。你写代码的时候，编译器不会帮你决定写什么逻辑，但它会检查你的类型是否匹配、边界是否越界、调用是否合法。SKILLGUARD 在物理世界智能体里扮演的就是这个角色：策略层说“我要调用抓取技能，参数是力度0.6、速度0.3”，SKILLGUARD 会检查当前夹爪状态是否允许、目标物体重量是否在技能标称范围内、周围是否有障碍物、力度和速度的组合是否在安全区间内。如果任何一项不满足，它直接拒绝这次调用，并返回一个明确的错误码，让策略层去处理。
2.1 为什么需要独立的守卫层而不是把检查写进技能里
把安全检查写进技能里，看起来更简单，但实际会带来三个问题。第一，技能会变得不可复用。如果每个技能都内置一套“当前场景是否安全”的判断，那这个技能就绑定了特定场景，换一个产线、换一种物料，技能就得重写。第二，检查逻辑会重复。多个技能可能需要同样的“碰撞检测”“力矩限制”“速度约束”，写多份不仅浪费，还容易不一致。第三，策略层会失去可见性。如果技能内部悄悄做了降级或回退，策略层根本不知道发生了什么，就无法做出正确的后续决策。
独立的守卫层解决了这些问题。它把“安全约束”从技能中抽离出来，变成一组可配置、可验证、可复用的规则。技能只负责执行，策略只负责决策，守卫负责说“可以”或“不可以”。这种分层在软件工程里很常见，但在物理世界智能体里，它的价值被放大了十倍，因为物理世界的错误代价太高了。
2.2 SKILLGUARD 的典型检查项与配置方式
在实际部署中，SKILLGUARD 的检查项通常分为三类：状态检查、参数检查、环境检查。状态检查关注智能体自身的状态，比如关节是否在限位内、夹爪是否已闭合、电池电量是否充足。参数检查关注策略层传入的参数是否在技能标称范围内，比如力度是否超过物体承重、速度是否超过安全阈值。环境检查关注外部条件，比如工作空间内是否有人员、障碍物距离是否足够、通信延迟是否在可接受范围。
配置方式上，我倾向于用声明式的规则文件，而不是硬编码。比如用 YAML 定义每个技能的守卫规则：
skill: grasp guards: - type: state condition: "gripper.state == 'idle'" error_code: E_GRIPPER_BUSY - type: parameter field: force range: [0.1, 0.8] error_code: E_FORCE_OUT_OF_RANGE - type: environment condition: "obstacle_distance > 0.3" error_code: E_OBSTACLE_TOO_CLOSE这样配置的好处是，策略层在调用技能之前可以先查询守卫规则，提前知道哪些参数组合是合法的，而不是等到调用被拒绝才去调整。这就像编译器在编译期就能发现类型错误，而不是等到运行时才崩溃。
3. 策略层的设计：从任务队列到动态编排
策略层是整个系统的“大脑”，但它不是那种什么都管的中央大脑，而是一个任务驱动的编排器。它的核心工作可以概括为四步：接收任务、分解任务、选择技能、监控执行。听起来简单，但每一步都有很多细节。
3.1 任务分解的粒度控制
任务分解太粗，策略层就变成了一个简单的“调用-等待”循环，无法应对执行中的变化；分解太细，策略层就会陷入琐碎的状态管理，失去全局视野。我的经验是，分解粒度应该以“技能调用”为基本单位。一个任务被分解成一系列技能调用，每个调用都有明确的输入输出和成功条件。策略层不需要关心中间的微观状态，只需要关心每个技能调用是否成功、是否需要重试、是否需要切换策略。
举个例子，一个“将包裹从传送带放到货架”的任务，可以分解为：定位包裹、抓取包裹、移动到货架、放置包裹、确认放置。每个步骤对应一个技能调用。策略层负责决定这些调用的顺序、参数、超时时间、失败回退。如果“抓取包裹”失败，策略层可以选择重试、调整抓取参数、或者放弃当前包裹转去处理下一个。这种粒度既不会太粗也不会太细，刚好能让策略层有足够的决策空间。
3.2 动态编排中的优先级与抢占
物理世界的一个特点是，任务不是孤立执行的。传送带上可能有多个包裹，多个工位可能同时请求机械臂，紧急任务可能随时插入。策略层必须能够处理优先级和抢占。我通常会把任务分为三个优先级：紧急任务、常规任务、填充任务。紧急任务可以抢占正在执行的常规任务，但抢占时必须确保当前技能处于安全的中断点，比如夹爪已经闭合、物体已经放置稳妥。
抢占的实现依赖于技能层的“可中断性”。不是所有技能都可以随时中断，比如“抓取”技能一旦开始，中途中断可能导致物体掉落。所以策略层在抢占之前，必须查询当前技能的“中断点”信息。这也是编译型技能的一个优势：技能在编译阶段就标注了哪些状态是安全中断点，策略层可以直接查询，而不需要猜测。
3.3 策略的在线调整与离线验证
策略层不能只在运行时工作，它还需要离线验证。我习惯把策略逻辑写成可测试的模块，用模拟器回放历史数据，验证在不同场景下的决策是否正确。比如，用过去一周的产线数据回放，看看策略层在传送带堵塞、包裹堆叠、设备故障等场景下是否做出了合理的决策。这种离线验证可以在不碰真实设备的情况下发现大部分逻辑错误。
在线调整则更微妙。物理世界的环境会漂移，比如传送带速度因为磨损而变慢、夹爪因为老化而力度下降。策略层需要能够感知这些漂移并调整参数。我的做法是给策略层加一个“性能监控”模块，持续跟踪每个技能的成功率、平均执行时间、失败模式分布。当某个指标偏离基线超过阈值时，策略层自动调整相关参数，比如增加抓取力度、延长超时时间、降低速度。这种自适应调整不需要重新训练模型，只需要在策略层做参数微调。
4. 编译型技能的构建流程：从模型到契约
把技能从“模型”变成“契约”，需要一个明确的构建流程。我把它分为五个阶段：技能定义、接口编译、守卫绑定、模拟验证、部署注册。每个阶段都有具体的产出物，确保技能在进入策略层之前是“可编排”的。
4.1 技能定义：明确输入输出与失败模式
技能定义是整个流程的起点。你需要明确回答：这个技能做什么、输入是什么、输出是什么、在什么条件下可靠、可能怎么失败。我通常用一个结构化的技能描述文件来记录这些信息：
skill: grasp description: "从当前视野中抓取指定物体" inputs: object_id: string force: float speed: float outputs: grasp_success: bool object_pose: pose preconditions: - "gripper.state == 'idle'" - "object.in_view == true" postconditions: - "grasp_success == true implies gripper.holding == object_id" failure_modes: - code: E_GRASP_EMPTY description: "夹爪闭合但未检测到物体" - code: E_GRASP_SLIP description: "抓取后物体滑脱" - code: E_GRASP_TIMEOUT description: "抓取超时" recovery: - E_GRASP_EMPTY: ["retry", "relocate"] - E_GRASP_SLIP: ["retry_with_higher_force", "abort"] - E_GRASP_TIMEOUT: ["retry", "abort"]这个文件就是技能的“契约”。策略层只需要读这个文件，就知道怎么调用、怎么处理失败，不需要了解底层模型。
4.2 接口编译：把模型封装成可调用单元
接口编译阶段是把训练好的模型封装成符合契约的可调用单元。这一步的关键是隔离：模型内部的实现细节不应该暴露给策略层。比如，抓取模型可能是一个视觉-运动联合网络，输入是RGB-D图像和物体ID，输出是关节轨迹。但策略层看到的只是“输入object_id、force、speed，输出grasp_success和object_pose”。中间的图像处理、轨迹生成、运动控制都被封装在技能内部。
这种隔离带来的好处是，你可以替换底层模型而不影响策略层。比如，你把抓取模型从基于视觉的方案换成基于触觉的方案，只要输入输出契约不变，策略层完全不需要改动。这在长期维护中非常重要，因为物理世界的模型迭代速度很快，但策略逻辑相对稳定。
4.3 守卫绑定：把安全约束附加到技能上
守卫绑定是在技能上附加 SKILLGUARD 规则。这些规则可以来自技能定义文件，也可以来自全局配置。比如，全局配置可能规定“任何技能调用时，如果工作空间内有人员，必须拒绝执行”。这种全局规则会自动附加到所有技能上，不需要每个技能单独配置。
守卫绑定的一个关键决策是：守卫是在技能调用前检查，还是在技能执行中持续检查。我的做法是两者都要。调用前检查是“准入控制”，确保技能在合法状态下启动；执行中检查是“运行时监控”，确保技能在执行过程中不会因为环境变化而变得不安全。比如，抓取技能启动时工作空间是安全的，但执行中如果有人靠近，运行时守卫应该立即触发紧急停止。
4.4 模拟验证：在虚拟环境中跑通所有失败路径
模拟验证是编译流程中最容易被跳过、但最重要的一步。很多团队在真实设备上测试技能，只测试成功路径，不测试失败路径。结果上线后一遇到异常就手足无措。我的做法是，在模拟器中强制触发每一种失败模式，验证策略层是否能够正确处理。
比如，对于抓取技能，我会在模拟器中设置“物体突然消失”“夹爪力度不足”“物体重量超出预期”等场景，观察策略层是否按照契约中的恢复接口做出正确反应。如果策略层在某个失败模式下没有对应的处理逻辑，那就说明契约定义不完整，需要回到技能定义阶段补充。
4.5 部署注册：让策略层发现并调用技能
部署注册是最后一步。技能编译完成后，需要注册到策略层的技能库中，让策略层能够发现和调用。注册信息包括技能名称、版本、输入输出契约、守卫规则、性能基线。策略层在运行时根据任务需求查询技能库，选择合适的技能。
注册时我通常会加一个“灰度”机制：新技能先以低优先级注册，只处理少量任务，观察其成功率、执行时间、失败模式是否与模拟验证一致。如果一致，再逐步提高优先级；如果不一致，立即回滚。这种灰度机制在物理世界尤其重要，因为真实环境的噪声和模拟器总有差距。
5. 实测中的意外情况与排查链路
理论说再多，不如一次真实的踩坑。我在一个物流分拣场景中部署这套架构时，遇到了一个非常典型的问题：策略层在传送带堵塞时，会不断重试抓取技能，导致机械臂在同一个位置反复动作，最终触发过热保护。这个问题在模拟器中没有出现，因为模拟器的传送带不会“堵塞”——它只会停止，而停止状态下抓取技能会直接返回“无物体”，策略层会跳过。但真实场景中，传送带堵塞时物体还在，只是位置不对，抓取技能会反复尝试并失败。
5.1 问题现象与初步定位
现象是：机械臂在某个工位反复执行抓取动作，每次失败后立即重试，大约30秒后关节电机温度报警，系统停机。查看日志发现，策略层在收到 E_GRASP_EMPTY 错误后，按照契约中的恢复接口选择了“retry”，但没有限制重试次数。技能定义中虽然写了“retry”，但没有规定“最多重试几次”和“重试间隔”。
初步定位到两个问题：一是策略层缺少重试次数限制，二是技能定义中的恢复接口不够具体。但更深层的问题是，策略层没有感知到“传送带堵塞”这个全局状态。它只看到了单个技能调用的失败，没有看到失败背后的系统性原因。
5.2 根因分析：策略层缺少全局状态感知
进一步排查发现，策略层在编排任务时，只关注单个任务的执行状态，不关注产线的全局状态。传送带堵塞是一个全局事件，它会影响多个工位的任务执行。但策略层没有订阅这个事件，所以它不知道当前失败不是孤立的，而是系统性的。
这暴露了一个设计缺陷：策略层需要有一个“全局状态黑板”，用来共享产线状态、设备状态、环境状态。技能调用失败时，策略层应该先查询黑板，判断失败是孤立的还是系统性的。如果是系统性的，应该暂停相关任务，等待全局状态恢复，而不是盲目重试。
5.3 修复方案与验证过程
修复方案分三步。第一步，在策略层增加“全局状态黑板”，订阅传送带状态、工位占用、设备健康等事件。第二步，在技能契约中增加“重试策略”字段，明确最大重试次数、重试间隔、退避策略。第三步，在 SKILLGUARD 中增加“系统性失败检测”规则，当同一技能在短时间内失败超过阈值时，自动触发熔断，拒绝后续调用并通知策略层。
skill: grasp retry_policy: max_retries: 3 interval: 0.5 backoff: exponential circuit_breaker: failure_threshold: 5 window: 10 cooldown: 30验证过程用了两周。第一周在模拟器中回放历史堵塞数据，确认策略层在堵塞发生时能够正确熔断并等待。第二周在真实产线中灰度部署，观察熔断触发次数和恢复时间。最终结果是，堵塞场景下的无效重试减少了95%，电机过热报警不再出现。
5.4 举一反三：类似坑的预防清单
这个坑让我总结了一份预防清单，后来每次部署新技能都会对照检查：
- 技能契约中是否明确了最大重试次数和退避策略？
- 策略层是否有全局状态感知能力？
- SKILLGUARD 是否有熔断机制？
- 模拟验证是否覆盖了系统性失败场景？
- 灰度部署时是否监控了重试率和熔断率？
这份清单后来帮我们避免了好几个类似问题，比如移动机器人在通道拥堵时反复规划路径、装配机器人在零件缺失时反复尝试抓取。
6. Agent Skills 测试：怎么验证策略层真的“聪明”
Agent Skills 测试是最近很热的一个话题，但大多数讨论集中在数字世界的Agent上，比如网页操作、API调用、代码生成。物理世界的Agent Skills测试要复杂得多，因为你需要验证的不只是“技能能不能用”，而是“策略层能不能在正确的时间用正确的技能”。
6.1 测试用例的设计：从单技能到多技能编排
单技能测试相对简单：给定输入，验证输出是否符合预期。但策略层测试需要设计多技能编排场景。我通常把测试用例分为四个层次：
- 单技能正确性：技能在标称条件下是否成功。
- 单技能边界：技能在边界条件下是否安全失败。
- 多技能顺序：策略层是否能按正确顺序调用技能。
- 多技能冲突：策略层是否能在技能冲突时做出正确取舍。
比如，一个“抓取-移动-放置”的测试用例，不仅要验证每个技能单独成功，还要验证策略层在“抓取成功但移动超时”时是否能够正确回退到“释放并重试”，而不是带着物体继续移动。
6.2 模拟环境与真实环境的测试差异
模拟环境测试的优点是可控、可重复、成本低，但缺点是“太干净”。真实环境有噪声、有延迟、有磨损、有意外。我的经验是，模拟环境用来验证逻辑正确性，真实环境用来验证鲁棒性。两者不能互相替代。
在模拟环境中，我会故意注入噪声：给视觉输入加随机扰动、给执行器加延迟、给传感器加漂移。这样可以让策略层在模拟阶段就暴露一些鲁棒性问题。但即便如此，真实环境中总会有模拟器没有建模的因素，比如光照变化、地面振动、通信丢包。所以真实环境测试必须留足时间，不能指望模拟通过就万事大吉。
6.3 测试指标：成功率、恢复率、编排效率
评估策略层不能只看任务成功率。我通常跟踪三个指标：首次成功率、恢复成功率、编排效率。首次成功率反映技能本身的可靠性；恢复成功率反映策略层在失败后的处理能力；编排效率反映策略层在多个任务之间的调度能力，比如单位时间内完成的任务数、平均等待时间、技能切换次数。
这三个指标结合起来，才能全面反映策略层的“聪明程度”。一个策略层可能首次成功率很高，但一旦失败就完全无法恢复；另一个策略层可能首次成功率一般，但恢复能力很强，整体任务完成率反而更高。在物理世界中，后者往往更有价值，因为物理世界的失败是常态，恢复能力才是关键。
7. 从第一性原理看编译型智能体技能
Claude Agent Skills 的第一性原理讨论最近很火，但大多数讨论集中在“技能应该如何抽象”“技能应该如何组合”这些软件层面的问题。物理世界的编译型智能体技能，需要从更底层的第一性原理出发：物理世界的约束是不可协商的，技能必须在这个约束下定义自己的边界。
7.1 物理约束如何反向定义技能边界
在数字世界，你可以定义一个“发送邮件”技能，输入是收件人、主题、正文，输出是成功或失败。这个技能的边界很清晰，因为数字世界的操作是离散的、可逆的、低成本的。但在物理世界，定义一个“抓取”技能就复杂得多。抓取的边界不仅取决于物体本身，还取决于夹爪状态、物体姿态、周围障碍、地面摩擦、甚至空气湿度。这些因素中任何一个变化，都可能让原本可靠的技能变得不可靠。
所以物理世界的技能边界不是“设计”出来的，而是“发现”出来的。你需要通过大量实验，找到技能在哪些条件下可靠、哪些条件下不可靠，然后把这些条件写进契约。这个过程很像编译器在编译期做类型推导：它不是发明类型，而是发现代码中隐含的类型约束，然后显式表达出来。
7.2 技能组合的爆炸问题与策略层的剪枝
物理世界的技能组合是爆炸性的。假设你有10个技能，每个技能有5个参数，每个参数有3个可能取值，那么理论上的组合空间是 10 × 3^5 = 2430 种。如果考虑技能之间的顺序，组合空间更大。策略层不可能穷举所有组合，它必须剪枝。
剪枝的依据来自技能契约中的前置条件和后置条件。如果技能A的后置条件不满足技能B的前置条件，那么A和B就不能直接组合。这种基于契约的剪枝，可以在策略层运行时快速排除大量无效组合，把搜索空间缩小到可管理的范围。这也是编译型技能的一个核心优势：契约让组合变得可计算。
7.3 策略层的可解释性与可审计性
物理世界的智能体还需要面对一个数字世界不太关心的问题：可解释性和可审计性。当机械臂发生碰撞时，你需要能够回溯：策略层为什么在那个时刻调用了那个技能？守卫层为什么没有拦截？技能为什么没有按预期执行？如果策略层是一个黑盒神经网络，这些问题很难回答。但如果策略层是基于规则的编排器，每个决策都有明确的依据，回溯就变得可行。
我的做法是给策略层的每个决策打日志：任务ID、当前状态、候选技能、选择理由、守卫检查结果、执行结果。这些日志不仅用于事后审计，也用于在线监控和离线分析。当系统出现异常时，你可以快速定位是策略层的决策问题、守卫层的配置问题、还是技能层的执行问题。
8. 落地建议：从单工位到多工位的扩展路径
如果你正在考虑在物理世界中部署编译型智能体技能，我的建议是不要一上来就做全产线。先从单工位开始，把一个技能做深做透，把契约写清楚，把守卫配完整，把测试跑充分。单工位跑通之后，再扩展到多工位。
8.1 单工位验证：把一件事做到极致
单工位阶段的目标不是“做很多事”，而是“把一件事做到可重复、可验证、可恢复”。选择一个相对可控的场景，比如固定位置的抓取放置，把技能契约、守卫规则、策略逻辑都打磨到稳定。这个阶段可能会花掉整个项目一半的时间，但它是值得的，因为后面所有扩展都建立在这个基础之上。
8.2 多工位扩展：策略层的分布式编排
多工位扩展时，策略层需要从单机编排变成分布式编排。多个工位可能共享机械臂、共享传送带、共享物料。策略层需要处理资源竞争、任务优先级、全局状态同步。这时候，全局状态黑板变得更重要，守卫层也需要支持跨工位的约束检查，比如“机械臂正在服务工位A，工位B的请求必须等待”。
分布式编排的一个关键决策是：策略层是集中式还是分布式。集中式策略层容易做全局优化，但单点故障风险高；分布式策略层容错性好，但全局优化困难。我的经验是，在中小规模场景中用集中式，在大型场景中用“集中+分布”混合模式：全局策略层负责跨工位调度，本地策略层负责单工位内的技能编排。
8.3 持续迭代：从日志到策略优化
部署不是终点，而是起点。物理世界的环境会变化，技能会老化，任务会演变。你需要建立一套持续迭代机制：收集日志、分析失败模式、调整策略参数、更新技能契约、重新验证。这个循环越快，系统的适应能力越强。
我通常每周做一次日志分析，每月做一次策略调优，每季度做一次技能契约审查。这个节奏不是固定的，取决于场景的变化速度。变化快的场景可能需要每天分析、每周调优。关键是不要让系统“僵化”——物理世界的智能体必须能够随着环境一起进化。
我在实际项目中最深的一个体会是：编译型智能体技能的价值不在于技能本身有多强，而在于它让策略层变得可构建、可验证、可迭代。没有契约的技能是一盘散沙，有契约的技能才是一个可编程的系统。而策略层，就是这个系统的编译器——它把任务编译成技能调用序列，把环境状态编译成决策依据，把失败编译成恢复路径。这个过程越清晰，物理世界的智能体就越可靠。
