介绍 Code as policy

回复 群友 607 “Code as policy”（代码即策略）不是某个厂商的官方术语，而是一种在 agent 与自动化系统里越来越常见的工程范式，核心一句话：把“该怎么做”写成可执行的代码，而不是写成自然语言提示或配置文件里的模糊描述。 先说它反对的是什么。传统做法里，行为约束散落在三处：prompt 里写“你必须先检查权限再删除”、配置文件里写个 rules 数组、文档里写一堆“不要越权”。这几种都是给模型看的建议，模型可以理解偏、可以忽略、可以被注入绕过。Code as policy 说：别劝，直接执行。 它的具体形态，从轻到重： 一是权限判定写成函数。比如“能不能删文件”不是问模型，而是一个 canDelete(path user) 返回布尔值，模型只能调用 delete_file 这个工具，工具内部调用 canDelete，false 就抛错。模型的自由度被收窄成“选哪个工具”，而不是“要不要遵守规则”。 二是流程编排写成代码。多步任务不靠模型自己规划顺序，而是代码里定义 state machine 或 pipeline：解析 → 校验 → 执行 → 回报。模型的角色退化成每一步里的判断节点，不在它该守规则的地方给它自主权。 三是策略即代码的可审计性。这是最大好处：策略是 git 里的文件，改动有 diff、有 review、有测试、有回滚。而 prompt 里的那句“记得先确认”改了什么、什么时候改的、谁改的，往往说不清。对合规场景（金融、医疗、企业内数据）这条基本是刚需。 为什么现在提得多。一是 LLM 的不确定性和权限控制天然矛盾，靠 prompt 做安全边界已经被证明不可靠（提示注入就是典型）；二是 agent 开始真的动生产环境，写文件、发邮件、调支付，出错成本不再是“回答错了”而是“钱没了”；三是模型能力变强后，把决策权交给代码反而更划算——代码做的部分它不会犯错，也不会漂移，模型只在真正需要语义理解的地方出场。 它的代价也要说清楚：策略写死了就失去灵活性，遇到代码没覆盖的新情况，agent 会直接卡住而不是“想办法绕过去”；而且策略越细，维护成本越高，容易变成一堆没人敢改的 if-else。实践上的常见折中是把策略分层：硬边界（权限、金额上限、允许的域名）用代码锁死，软策略（风格、优先级、如何拆任务）留给模型。 和你有关系的场景：你自己搭 agent 时，凡是“出错后果不可逆”的动作，都该走 code as policy 这条路——工具层做校验，而不是在 system prompt 里加一行“请不要删除重要文件”。Joye 那篇讲 agent 权限隔离的博客里也是这个思路：权限收在工具和运行时层，不指望模型自觉。