这里的 Canon不是相机品牌也不是打印机驱动而是一套把模型提示词和 Agent 之间通信统一到“受控英语”上的方案。项目标题里的关键词很直接controlled English for model prompting and agent-to-agent communication也就是用一套受限、规则化的英语子集去约束大模型的输入指令也约束多个 Agent 之间的消息传递。我最近在实际链路里试过类似的思路最大的感受是它解决的不是“模型能不能听懂”的问题而是“模型每次听懂的结果是否一致、是否可解析、是否可以稳定交接”的问题。如果你正在做 LLM 应用、Prompt 工程或者打算搭一套多 Agent 协作系统这篇文章值得往下看。最值得关注的点不是语法本身而是这种“受限表达”能帮你把不可控的自然语言交互收敛成可测试、可回放、可批量验证的工程链路。下面按实际落地顺序拆开讲。1. 先搞清楚 Canon 这类受控英语解决什么问题1.1 模型提示词为什么需要“受限表达”大模型最强的地方是开放语言理解最麻烦的地方也是开放语言理解。同一句话换个说法模型可能给出不同动作同一段业务指令今天跑和明天跑结果也可能不一样。举个很常见的例子帮我查一下订单然后如果没问题就发货顺便把物流单号告诉我。这句话人看没问题但交给模型以后至少有四个模糊点“查一下订单”没有说查哪个订单“没问题”到底是什么标准“发货”走哪家物流“顺便”意味着优先级低可能被模型忽略。在闲聊场景里这种模糊可以容忍。但在生产链路里每个模糊点都可能变成一次错误执行。Canon 这类受控英语的思路就是主动砍掉这种自由度。它把允许使用的动词、字段名、条件判断、响应格式都限定住模型只能在有限的组合空间里生成内容。这样做好处很直接输出可预测了错误可定位了测试可自动化了。1.2 Agent 之间为什么不能直接自由对话多 Agent 系统里问题会更明显。假设你有一个规划 Agent、一个执行 Agent、一个复核 Agent它们之间如果靠自由文本互相传消息每一轮都会发生一次“二次理解”。A 告诉 BIt looks okay, ship it.B 接收到之后首先要判断 “it” 指什么“okay” 的判断标准是什么“ship” 要调哪个接口。如果这个系统只有两个 Agent还能靠模型上下文硬撑。一旦链路变成五个 Agent、十轮交接每轮都有信息损耗最后得到的输出可能已经和原始目标偏差很大。Canon 的作用是给 Agent 之间定一套“双方都认的消息契约”。执行方不需要再靠意图猜测而是直接解析受控语句里的动词、对象、条件、字段值。这比自由文本更可靠又比纯 JSON Schema 更接近自然语言人看日志的时候不会觉得像在读乱码。1.3 它不是用来替代所有提示词而是给关键链路加“紧箍咒”有一点要先说清楚受控英语不是要废掉自然语言 Prompt。创意写作、头脑风暴、开放式问答这些场景强行套受控语法反而会削弱模型能力。Canon 最适合的场景是那些“出错了代价很高”的关键链路。我自己的判断标准是三条这个任务是否会被高频重复执行这个任务的输出是否会被程序解析和二次使用这个任务如果出错是否会造成资金、库存、权限、数据上的实际影响如果三个都满足就值得用受控英语。如果只是让模型帮忙写一段文案那保持自由表达就好。Canon 更准确的定位是给关键链路上的动作和响应加一道“紧箍咒”而不是把整条路都铺成固定轨道。2. 从普通提示词到受控英语设计思路与最小语法2.1 受控英语的典型组成受控英语并不是“把句子写简单”这么简单。它更像是一套微型语法体系核心要控制住四样东西。第一是动作动词。每个动作都对应一个明确的系统操作比如 query、check、create、update、ship、return、notify。动词不能随意扩展能不用近义词就不用近义词。今天用 “query order”明天就不要改成 “look up order” 或 “fetch order”。第二是对象和字段名。order、inventory、user、shipment、invoice 这些对象要有统一定义。字段名也要固定比如 order_id、tracking_id、carrier、stock_count。字段名模糊解析逻辑就会跟着混乱。第三是条件表达。受控英语里最常见的就是where条件用来限定查询或动作范围。比如where order_id SO-2024-001。这里的关键是值类型保持一致字符串统一用单引号数字直接写日期用 ISO 8601。第四是响应格式。模型回答也要受控。不能说一堆解释而是直接回答指定字段比如respond with order_status, tracking_id。响应格式一旦明确下游脚本就能稳定解析。这里给出一套最小示例语法先不要追求完整够用就行action : query | check | create | update | ship | return | notify | confirm object : order | inventory | user | shipment | invoice | task condition : field value | field number | field number response : respond with field [, field ...]2.2 Canon 式表达的基本语法约定示例Canon 项目本身在标题里没有给出具体语法文档所以下面给的是我在类似受控英语实践里常用的一套写法不代表 Canon 的最终规范。真正落地时以你使用的实现文档为准但设计原则是通用的。示例语句query order where order_id SO-2024-001 check inventory for sku KB-2210, quantity 3 if stock_count 3 then ship order where order_id SO-2024-001 via carrier standard respond with order_status shipped, tracking_id SF123456这些语句有几个共同特点动词放在最前面一眼就能看出意图。对象紧跟在动词后明确操作对象。where用来写过滤条件。respond with明确告诉模型“你只需要回答这些字段”。字符串字段统一加单引号避免空格和特殊字符干扰解析。如果一个业务动作无法用这套结构表达那通常不是语法不够而是这个动作本身还没被定义清楚。这时候先回业务侧把输入和输出敲定不要急着往语法里加新句式。2.3 一个最小可运行示例把模糊业务描述改写成 Canon 表达还是回到上面那个模糊需求帮我查一下订单然后如果没问题就发货顺便把物流单号告诉我。把它拆成 Canon 表达可以写成四步query order where order_id SO-2024-001 check order where risk_flag low ship order where order_id SO-2024-001 via carrier standard return tracking_id, estimated_delivery_date每一步对应一个确定动作每个动作的输入参数都是明确字段。模型不再需要猜测“没问题”是什么意思因为风险判断已经被收敛成risk_flag low这样一个可检查条件。喂给模型的提示词可以这样组织You must respond in Canon. Allowed actions: query, check, ship, return. All fields must use these names: order_id, risk_flag, carrier, tracking_id, estimated_delivery_date. Response example: query order where order_id SO-2024-001注意这里没有让模型自己发挥而是明确告诉它“必须用这种格式回答”。刚开始模型可能还会多输出解释性文字这很正常需要跑几次之后一边调整提示词一边收紧输出格式。3. 在 Prompt 中使用受控英语实操流程与参数判断3.1 单条 Prompt 的改写步骤我建议把每次改写都走成固定五步不要凭感觉写。第一步提取真实意图。先不去管用户怎么说而是问这个请求最终要触发哪个系统动作查订单改状态发货通知第二步找出实体和条件。订单号是多少库存量是多少风险等级阈值是多少这些信息如果在用户原话里没有就要通过上下文补齐或者在 Prompt 外围先做一轮字段抽取。第三步映射到允许的动作。把真实意图对应到受控英语的动词表里。如果动词表里没有就先停下来确认这个动作是不是真的需要支持。第四步定义响应字段。明确“模型回答里必须包含哪些字段”。这一步很关键很多解析失败不是因为模型笨而是因为 Prompt 没有规定回答结构。第五步跑一条测试。先不管复杂场景拿一条最典型的输入试跑看输出能不能被脚本解析成预期结构。能跑通再继续扩。3.2 判断 Prompt 是否“受控”成功的标准判断一套受控 Prompt 成不成功不能只看“模型这次回答对不对”。要有一套可量化的判断维度。我一般会看四个指标可解析率输出能否被脚本成功转换成结构化数据。比如用正则或简单解析器把status shipped解析成字典。字段齐全度respond with要求的字段是否全部出现有没有漏字段。语义一致性同一输入跑三次结果是否一致。输出长度回答是否稳定在较短范围内。如果模型每次都额外解释一大段说明受控还没到位。指标看什么判断标准可解析率输出能被脚本结构化成功的比例低于 90% 不要进批量字段齐全度响应字段是否都存在必须 100%语义一致性同一输入多次结果是否稳定结果应基本一致输出长度回答的 token 数是否稳定应该短且稳定如果四个指标都不达标先别急着调模型参数优先检查 Prompt 里有没有给出足够的格式约束和示例。很多时候加一个respond with模板比调温度参数管用得多。3.3 批量改写和模板化让提示词可复用单条跑通之后下一步是把受控英语做成模板让它能批量处理。这里不是让大家写复杂代码而是先把“动作、字段、响应格式”从 Prompt 里抽出来变成一份可维护的配置。一份最小配置可以长这样allowed_actions: - query order - ship order - return tracking_id response_fields: - tracking_id - estimated_delivery_date temperature: 0 max_tokens: 128 stop_sequences: - \n代码侧只需要把用户输入里的字段值填充进模板然后统一调用模型接口。这里有一个很关键的经验批量任务不要一上来就开最大并发。我的习惯是先用 5 到 10 条样例跑一遍记录每条的解析结果和失败原因确认输入字段都是干净的再逐步提高并发。批量任务里最常见的错误不是模型崩了而是数据源里某些字段为空、格式不对、订单号带了多余空格。输入不干净Prompt 再怎么受控都没用。4. Agent 之间通信为什么要一套“双方都认的 Canon 语言”4.1 自由文本协议在高频协作里的问题如果只是单个 Agent 完成任务方案可以很随意。但 Agent 一多消息就成了关键瓶颈。自由文本协议看起来灵活实际跑起来问题很多。接收方需要通过模型做二次理解理解错了后面的动作就全错。而且自由文本缺少稳定的状态码问题排查只能靠人肉读日志。比如执行 Agent 返回一句 “sorry, it failed”规划 Agent 根本不知道下一步该重试、换方案还是终止任务。这时候如果用结构化 JSON 做消息机器解析是简单了但模型生成 JSON 时容易出现字段拼错、嵌套错误、多一个逗号少一个括号的问题。而且纯 JSON 的可读性差排错时要来回对照字段名。受控英语正好卡在两者之间。它保持了接近自然语言的可读性同时因为语法受限又可以被确定性解析器处理。4.2 Canon 消息的常见结构Agent 之间通信时我一般不会让整条消息都变成纯文本而是采用“JSON 外壳 Canon 载荷”的结构。外壳负责寻址和路由里面塞的是一段受控英语语句。这样机器可以靠外壳里的 sender、receiver、intent 快速转发模型或解析器再处理里面的 Canon 载荷。{ sender: planner, receiver: executor, intent: ship_order, request_id: req_12345, payload: ship order where order_id SO-2024-001 via carrier standard }这个结构的好处是定位快速日志可读负载不高。排查问题时直接看 payload 就能明白 Agent 之间发生了什么程序处理时也能按 intent 路由到对应处理器。4.3 场景示例两个 Agent 用 Canon 语言完成一次任务交接下面是一个简化的协作示例。规划 Agent 想确认库存于是发送check inventory for sku KB-2210, quantity 3执行 Agent 处理完后返回inventory_result sku KB-2210 available true, reserved_quantity 3规划 Agent 收到结果确认可以发货于是发送ship order where order_id SO-2024-001 via carrier standard执行 Agent 返回shipped order_id SO-2024-001, tracking_id SF123456如果库存不足执行 Agent 返回的错误也应该遵循统一格式error code INSUFFICIENT_STOCK, message only 2 in stock这套方式最明显的提升是任何一个环节出错都可以通过日志复现整条链路。哪条消息格式不规范、哪个字段缺失、哪个 Agent 没有按约定返回结果一眼就能定位。相比自由文本它把 Agent 之间的“对话损耗”降到了最低。5. 落地时如何验证效果环境、样例、指标、排查5.1 先从小样例开始验证我不建议一上来就构造一个超复杂的多 Agent 场景。受控英语的效果验证应该从最小样例开始。先挑 5 到 10 个有代表性的任务。所谓代表性不是最难的那几个而是最常用的那几个。比如查订单、查库存、改状态、生成物流单号。把这些任务分别写成 Canon 表达然后跑单轮测试。单轮测试通过后再跑多轮 Agent 交接。多轮测试时每一轮的输入都要用上一轮的输出这时最容易看到 Canon 表达是否真的稳定。如果第二轮开始出现格式漂移就要回到 Prompt 和语法定义里找原因。5.2 评价指标看什么受控英语的验证指标和普通 Prompt 质量的验证指标不太一样。普通 Prompt 更看重内容质量受控英语更看重结构稳定性和可解析性。指标看什么我的参考线可解析率输出能否被脚本转成结构化结果90% 以上再进批量字段齐全度要求返回的字段是否都在必须 100%语义一致性同一输入跑多次是否一致结果基本稳定输出长度回答的 token 数是否可控持续稳定或下降失败恢复率非法输出后重试的成功率越高越好这里要提醒一句指标只能帮你判断“当前方案适不适用”不能脱离业务场景直接抄数值。如果你的任务本身输入千奇百怪初期可解析率低于 90% 很正常先把输入清洗和字段规范化做好再回头看指标。5.3 常见报错和排查顺序接触受控英语的初期最常遇到的报错其实就那么几类。第一类模型仍然输出大段自然语言。原因通常是 Prompt 里没有明确限制输出格式或者没有给出足够少的示例。解决方法是把respond with模板加进系统提示词并给两三条完整示例。第二类输出里出现未知动作词。比如你只定义了 ship、query模型却输出了 dispatch。这说明动作词表还不够聚焦需要在 Prompt 里强调“只能用以下动作词”。第三类必填字段缺失。比如要求返回 tracking_id结果没有返回。解决方法是把响应字段写进模板并且用“必须包含”这样的强约束表达。第四类解析器在转义或引号上出错。这通常不是模型问题而是输入数据里的字符串带了特殊符号。先清洗数据再进模型。第五类值在业务系统里查不到。这种情况即使模型生成得再标准下游执行依然会失败。排查时要先确认输入数据是不是已经过时或者字段是不是填错。通用排查顺序我建议这样走先看现象是报错、卡住、无输出还是输出格式不对。再看输入字段是否为空、编码是否正确、路径是否完整。再看 Prompt动作词、字段名、响应格式是否约束到位。再看参数temperature、max_tokens、stop_sequences 是否符合解析需求。最后看运行环境依赖版本、权限、接口状态、并发是否过高。这条链路里最容易被忽略的是第二步。很多问题看起来是模型不会生成实际上是把脏数据喂给了模型。6. 边界与经验不是所有场景都适合受控英语6.1 哪些场景适合 Canon哪些不适合适合用受控英语的场景通常具备三个特征重复、结构化、出错成本高。比如订单管理、库存查询、物流状态更新、任务编排、API 参数生成、信息抽取。这些场景里的输入输出边界清晰适合用固定动词和固定字段描述。不适合用受控英语的场景是开放对话、创意写作、情感支持、头脑风暴、探索性分析。这些任务本身就依赖语言多样性强行受控会牺牲表达质量反而给用户带来机器感。如果你是个人开发者只是想跑通一个几十行的小工具受控英语不一定有显著收益。但如果你在做团队项目或者准备把多个 Agent 长期部署到生产环境那从第一天就定好受控表达规范会比后期返工省很多事。低配环境也能尝试。受控英语只是 Prompt 层面的约束不依赖额外算力。但如果你要把它做成完整的 Agent 通信协议那除了语言规范还要考虑消息队列、日志、失败重试、状态管理这些工程问题。6.2 从 Prompt 模板到微调项目演进路径大部分团队不需要一开始就微调模型。受控英语的落地我更推荐按阶段推进。第一阶段用系统提示词加几个示例把动作词、字段名、响应格式写清楚。大多数业务场景下这个阶段已经能解决 80% 的问题。第二阶段把 Prompt 做成模板加上校验脚本和失败重试。模型偶尔输出不合法内容时自动重试一次或两次能明显提升整体成功率。第三阶段如果任务量很大且模型在受控英语上的稳定性一直达不到要求再考虑收集“原始输入到 Canon 输出”的数据做一次小规模微调。第四阶段如果 Agent 之间需要高可靠通信再引入正式语法解析器对每条 Canon 语句做严格校验。不要跳步。我自己见过不少团队刚跑通两三个用例就急着微调、急着上并发最后往往卡在数据清洗和效果评估上回头还得重建 Prompt。6.3 我建议的落地清单如果现在准备在项目里引入 Canon 这类受控英语方案我建议按以下清单逐项检查。动作动词是否控制在 10 个以内且没有近义词混用。字段名是否有统一定义字符串、数字、日期格式是否固定。响应格式是否明确模型是否知道“只需要回答哪些字段”。是否准备了 5 到 10 条代表性测试样例。每条测试样例是否跑了至少三次确认结果稳定。输出是否可以被脚本稳定解析而不是靠人眼判断。是否有日志记录原始输入、模型输出、解析结果。是否对非法输出做了重试机制。批量任务前是否检查过输入数据质量。是否保留了自由文本场景的入口而不是一禁了之。踩过几次之后我发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。Canon 这类受控英语给模型搭了一个框架但框架能不能起作用取决于你有没有把动作、字段、响应格式先定义清楚。先跑稳单条再上批量先定协议再写解析器这个顺序不要反过来。