Agent skills: constraints over scripted workflows

「先 A 再 B 再 C」的脚本式流程，本质是假设世界状态可枚举、用户意图可预测。但工程里常见的是：工具返回值脏、用户半路改目标、上下文被截断、模型偶发抽风。流程写得越细，分支爆炸越快；每个新 corner case 都要改主流程，维护成本指数上升。

更麻烦的是：工作流把「怎么做」绑死了，却把「什么绝对不能做」「什么算完成任务」讲得不清楚。结果是模型在不该调用工具时调用、该停手时继续编、该拒答时硬答——这些都不是多塞两个 if 能根治的，需要边界语义前置。

几条对我自己最有用的轴（彼此叠加，而不是二选一）：

• 安全与权限：哪些 MCP / 子进程永远不可达、哪些目录只读、敏感字段不进日志——比「第 3 步必须调用某某工具」优先。
• 输出形状与契约：给用户什么粒度（一句结论 vs 可执行 checklist）、何时必须声明不确定性、引用与代码块规则——减少「看似专业其实幻觉」的损害面。
• 停机与升级条件：什么情况下必须停手问人、什么信号触发降级（例如只读检索不写盘）、何时把整个回答退回重试——比把 happy path 写满更有性价比。
• 可观测与可回放：边界触发时留下最小必要轨迹，方便事后对照 prompt / 工具版本——这是「约束」能持续迭代的燃料。

直觉上，约束是「护栏」，允许模型在护栏内用自身推理补全路径；工作流是「轨道」，一旦出轨就要全局改轨。前沿 AI 工程里，模型能力在变、工具在变，轨道老化得比护栏快。

Skill 的 description、触发词、规则文件，我会优先写清：何时启用、何时必须拒绝、工具与数据的边界、对用户可见的输出策略。具体「第几步调用哪个子 agent」反而倾向保持松散，用检查点（checkpoint）而不是细粒度脚本去串——除非领域真的强监管（金融清算、医疗处方等），那本来就该偏轨道。

和「规定路径」相比，约束优先更像在写小型「宪法」：条文少、可辩论、可版本化；工作流更像行政法规——条越多，越容易与现场脱节。

不是反对工作流——反对的是用工作流替代边界思考。Agent / Skill 真正难的是：在开放环境里做可靠决策；这件事上，边界比路径更长寿。后面若实践有变，会再写一篇把这条判断推翻或细化。