受控英语：从提示词工程到多Agent通信的稳定协议

如果让我用一个具体场景开场那就是去年底我帮朋友调试一个多 Agent 协作系统。最初的版本里每个 Agent 的提示词都写得非常“口语化”比如“分析一下这份数据然后把结果发给下一个模块”。单看任何一条提示都没问题但整套流程跑下来Agent 之间的交接经常出现信息丢失、字段对不上、任务理解漂移这种问题。后来我换了一种思路把所有跨 Agent 的指令收敛成一套限定词表、固定句式、结构化字段的写法问题才真正缓解。那次经历让我对 Canon-A 这个项目产生了兴趣。它的标题里有两个关键词“controlled English”受控英语和“agent-to-agent communication”Agent 到 Agent 的通信。乍看之下它只是在说“把提示词写得规范一些”但往深了想它其实在解决一个更底层的问题当模型不再只是和人对话而是和另一个模型协作时我们到底需要一种什么样的语言这篇文章我不会去复述某个项目的文档而是想把这个思路拆开看受控英语到底是什么、它能给提示工程和 Agent 通信带来什么、为什么它值得被认真对待以及落地时最容易被忽略的坑在哪里。1. 单次调提示词的快感掩盖不了跨人跨系统的歧义问题1.1 你写的“清楚”只是对自己清楚很多开发者第一次接触提示工程时都会经历一个“原来如此”的阶段同一个任务换一种说法模型输出质量就明显不同。于是大家开始疯狂调整措辞、补充上下文、设计 few-shot 示例。这个过程很容易让人产生一种错觉——只要我把提示词写得足够详细、足够清晰模型就能稳定执行。但这里有一个隐藏问题你说的“清晰”很可能是对你自己清晰。自然语言是一种高度依赖语境的符号系统。同一个句子在不同人的语感里可以有不同的重点。“尽量详细一点”“按需处理”“把结果发到下一个模块”这些话人懂但模型不一定按你想要的方式懂。更麻烦的是当多个 Agent 协同工作时每个 Agent 拿到的提示词可能是另一个人写的也可能是另一个 Agent 生成的。这时候“某个人的口头约定”就完全失效了。1.2 单 Agent 可以不追求规范多 Agent 必须追求可解析单 Agent 场景下你只需面对一个模型、一段提示、一次输出。即使提示词写得比较随意你还可以通过反馈、重试、人工修正来兜底。多 Agent 场景完全不同。Agent 之间要用自然语言传递任务、传递结果、传递状态。这意味着你不仅要确保“人”和“模型”之间能对上信号还要确保“模型”和“模型”之间能对上信号。如果每个人各自为政地写提示词整个系统的行为就会变得高度不可预测。我之前见过一个典型的失败案例一个 Agent 输出的报告里写了“已完成”下游 Agent 却把“已完成”和“处理成功”当成两种完全不同的状态结果整个流程卡在状态判断上。这种问题不是把提示词“加长”就能解决的。1.3 Canon-A 试图回答的问题不是一个单词表而是一套通信协议Canon-A 的关键不是把英语变成一种“机器语言”而是给英语加了一层“约法三章”。受控英语Controlled English并不是一个全新概念。在航空航天、医疗、法律等领域很早就有人尝试通过限制词汇量、固定句式结构、消除多义表达来提高文本的精确性和可解释性。Canon-A 的特殊之处在于它把这套思路应用到了模型提示和 Agent 通信上。换句话说Canon-A 真正想解决的问题不是“怎么让模型更聪明”而是“怎么让参与者之间的信息交换更不容易出错”。这里的参与者包括人类也包括模型更包括由模型驱动的一整个 Agent 系统。2. 受控英语不是“简化英语”它管的是表达边界2.1 先区分简化是减少表达负担受控是建立表达禁区很多人第一次接触受控英语容易把它理解成“用简单的单词、简单的句子写提示词”。这个理解只对了一半。简化英语的出发点是降低阅读门槛比如给非母语者看、给机器翻译用。但受控英语的出发点是约定什么能说、什么不能说。举个例子在受控英语体系里你可能会被要求使用固定动词表避免“get”“do”“handle”这类高歧义动词使用明确的主谓宾结构避免“如果可能的话”这类条件模糊的修饰用结构化字段描述任务状态而不是用“完成了”“还差一点”这种依赖语境的描述对每个指令标注明确的作用对象和期望输出格式。这已经不是“把话说得简单一点”了而是在创建一个表达边界允许范围内的表达模型必须能稳定解析边界以外的表达系统应该直接拒绝而不是猜测。2.2 为什么自然语言会把 Agent 通信变成一场“猜谜游戏”要理解 Canon-A 这类方案的价值得先理解为什么自然语言在 Agent 通信里会出问题。自然语言的特性是“高语境依赖”。同一个词在不同句子里含义不同同一个句子在不同上下文里含义不同更麻烦的是它允许省略、指代、隐喻、委婉表达。对单个人类读者来说这些特性是效率工具——我们可以快速理解省略的信息补全上下文。但对模型之间的通信来说这些特性就是不确定性来源。一个 Agent 说“这个结果不太行”另一个 Agent 该怎么理解“不太行”是格式问题、质量精度问题还是它的上游输入有问题如果这些信息不字段化、不结构化就会变成系统里的隐性需求最终导致错误被静默传递。受控英语的价值就是把“看起来自然但实际模糊”的表达替换成“看起来受限但实际明确”的表达。它牺牲了一部分自由度换取的是可解析性和确定性。2.3 从“人机对话”到“机机对话”语言要从表达工具变成协议传统的提示词工程本质上是人向模型“表达意图”。这个阶段自然语言是最高效的接口因为人类的思维天然适合自然语言。但 Agent 与 Agent 的通信本质上是两个系统在交换任务和结果。这时如果还用完整的自然语言当接口就会引入大量冗余信息、歧义信息和无效信息。更好的方式是把语言降级成一种“受限协议”只保留任务指令、状态字段、数据引用、明确条件判断这些核心成分。Canon-A 所代表的受控英语思路就是在尝试架设一座桥它保留了英语的阅读友好性让人类仍然可以读懂 Agent 之间的通信内容同时通过限制语法和词汇范围让模型之间可以稳定解析。这个思路很像“给自己人看的暗号”——外人可能觉得有点生硬但内部沟通效率极高。3. 提示词工程里怎么用受控英语不是全部重写而是分层约定3.1 判断一下哪些提示词最适合受控化不是所有提示词都需要受控化。如果只是让模型写一段营销文案、生成一个故事、头脑风暴几个点子自然语言越丰富越好强行加约束反而会让输出显得死板。真正适合受控英语的场景通常有这几个特征任务步骤固定比如“提取→清洗→分析→生成报告”输入输出明确每个环节都需要明确的字段和数据格式过程需要审计需要知道每一步基于什么判断、产生了什么结果多人或多 Agent 协作提示词不是一次性使用而是会被反复引用、组合、传递。如果符合这些特征那受控化就有价值。否则用自然语言写更省事也更符合模型的长处。3.2 一个可落地的受控提示词分层框架实际操作时我不建议把所有提示词从头到尾都改写成“受限英语”。那是极端做法成本高、维护难而且很多场景并不需要。更稳妥的方式是做一个分层处理第一层会话边界层。定义整个系统的人物角色、任务背景、输入输出格式、不允许触碰的边界。这层是全局约定所有 Agent 都要遵守。第二层任务指令层。用受限句式描述当前 Agent 到底要做什么。比如使用“从[数据源]提取[字段列表]”而不是“看看里面有什么有用的东西”使用“按[排序规则]对[数据集]排序”而不是“让结果看起来更有序一些”使用“如果[条件]为真执行[动作]否则执行[替代动作]”而不是“看着办”。第三层数据字段层。明确每一次 Agent 间传递的数据结构。比如定义task_id、status、input_ref、output_ref、error等字段并规定取值必须来自一个枚举范围。这套分层框架的好处是它不要求你把所有自然语言都消灭而是把最关键的地方——任务指令和数据结构——约束住让 Agent 之间有一个稳定的“接口”。3.3 受控化之后提示词会发生什么变化我们用一组对比来说明这个问题。假设你希望一个 Agent 处理完数据后把结果传给下一个 Agent。自然语言写法可能是分析一下这些数据把结果整理好然后交给下一个模块处理。记得写清楚一点。受控化之后的写法可能是任务analyze_data 输入数据data/input/20250101.csv 分析规则missing_rate 0.2 时标记为异常 输出字段summary, anomaly_list, data_quality_score 输出目标agent:data_reviewer 完成后状态analysis_completed两者都能被模型执行但执行稳定性完全不同。后者看起来不够“自然”但它把任务的边界、输入、规则、输出和流转目标都锁死了。任何一个下游 Agent 拿到这条信息都可以直接解析而不用再猜测“结果整理好”是什么意思。4. Agent 通信里用受控英语真正要解决的是状态与意图的歧义4.1 Agent 通信最怕的不是“内容看不懂”而是“状态猜不准”在我看过的多 Agent 项目里最常见的问题不是某个 Agent 能力不行而是 Agent 之间对“当前系统处于什么状态”的理解不一致。A Agent 说“处理完成”B Agent 可能理解为“可以进入下一步了”但 A 的实际意思是“这一步结束了但结果有问题需要人工介入”。一个状态词两种理解整个工作流就可能出现严重偏差。受控英语在这里的核心作用不是让文字更好懂而是让状态描述变成一个可以被程序判定的枚举值。比如你可以在系统里定义一套固定的任务状态词pending等待处理running执行中completed已成功完成failed执行失败needs_review结果可能有问题建议人工确认。然后再定义一个固定的“交接指令”格式TASK: [task_id] STATUS: [status] PAYLOAD: [data_ref] NEXT: [agent_id or human]所有 Agent 在通信时都使用这套格式。这个做法不是在限制模型的智能而是在给整个系统装一个统一的状态机协议。4.2 从“自然语言交接”变成“结构化交接”工作流才真正可控当 Agent 通信完全依赖自然语言时工作流的可控性会非常差。因为你没有一个明确的手段来验证“A 是否真的理解了 B 的意图”所有交接都建立在语义大模型的一次次实时推断上。但如果你把交接内容结构化很多问题就会提前暴露。比如缺少NEXT字段说明任务流定义不完整STATUS是一个非法值说明某个 Agent 的生成逻辑有 bugPAYLOAD指向的文件不存在说明上游数据处理没有完成。这些可不是语义问题而是可以直接被程序捕获的硬性错误。用受控英语做 Agent 通信本质上是把“我们相信模型能理解上下文”变成“我们约定好格式让模型在格式内表达”。这会让系统运行得更机械但也更可靠。对需要长时间运行的业务系统来说可靠性比灵活性更重要。4.3 一个值得注意的取舍受控英语不是“万能消歧工具”受控英语能够消除一部分歧义但它不是万能的。它解决的主要是“表达形式”层面的歧义比如词汇多义、语法含糊、信息缺失。但如果问题出在“模型本身的语义理解能力不足”或者“任务目标本身定义不清”那受控英语也救不了。举个例子如果你让 Agent 执行“生成一份高质量的市场分析报告”“高质量”本身就是一个模糊目标。你就算用最规范的句式来写模型也无从判断什么样的报告才算“高质量”。所以使用受控英语的一个重要前提是任务目标本身必须是可判定的。如果目标不可判定首要工作不是优化提示词而是重新定义任务把不可判定的目标拆解成可判定的子目标。5. 从普通提示词到受控英语一个渐进式迁移路径5.1 不要一次性推翻重写先拿一条链路做试点有些团队在尝试受控英语时会犯一个激进错误一次性把所有提示词和所有 Agent 通信格式全部改掉。结果往往是系统大面积报错最后只能回滚。更稳妥的路径是渐进式迁移。我建议按这个顺序走先选一条最核心、最频繁使用的任务链路作为试点把这条链路里 Agent 之间传递的数据字段和状态词先受控化保留面向人类用户的生成式提示词不变验证链路跑通后再逐步把更多任务纳入受控体系。这样做的原因很简单受控英语的核心收益在“跨 Agent 通信的确定性”不在“单个提示词写得好不好”。你只有把一条链路完整落地才能看到这个收益。5.2 落地时最容易踩的四个坑根据我接触过的类似实践有四个坑值得提前注意。坑一把受控英语做成“只有作者能看懂的黑话”。受控英语确实会引入一些固定表达和代码化字段但这不代表可以随意造词。任何新增的标准化表达都应该有明确的语义定义并且要让团队里所有人都能查阅。坑二只约束了输出没约束输入。有时候Agent A 的输出已经规范了但 Agent B 的输入是外部用户直接提供的自由文本。这时需要在入口处增加一个“转译层”把非受控表达转换成受控表达而不是指望外部输入自动符合规范。坑三过度受控把模型变成了模板引擎。受控英语的目的是消除歧义不是彻底禁止模型发挥。对需要创造性、需要语义推断的任务过度受控反而会牺牲模型的价值。正确的做法是区分“固定协议”和“弹性内容”协议部分受控内容部分保留空间。坑四只做了格式约定没做异常处理。受控英语能提高正确路径的执行效率但异常路径同样重要。比如某个 Agent 收到了一个不符合协议的输入系统该怎么办是拒绝、重试、降级还是转人工这些逻辑必须在协议设计时一并考虑。6. 排查链路当“受控化”之后 Agent 还是不符合预期6.1 先看现象再分层排查不要一上来就改提示词很多开发者遇到 Agent 行为异常第一反应是“我是不是提示词写得不够好”。但当你已经引入受控英语体系之后排查顺序应该变一下。我建议按这样一条链路排查第一步看协议层是否被绕过。检查 Agent 之间的实际通信内容看是否有 Agent 没有按照约定格式输出或者下游 Agent 是否试图解析非约定字段。很多异常根本原因是某个 Agent 没有彻底执行协议。第二步看输入数据是否符合约定。检查PAYLOAD指向的数据文件、字段列表、数据格式是否符合定义。受控英语约定的是表达方式但数据本身如果非法再规范的指令也无法产生正确结果。第三步看状态传递是否失真。检查每个 Agent 交接时的状态字段看status是否存在误用、丢失、覆盖的情况。状态字段是 Agent 间协作的命脉这个环节最容易出现“看起来成功实际逻辑不对”的问题。第四步看模型语义能力是否匹配。如果协议和数据都没问题但结果仍然不符合预期那就要考虑模型本身是否具备完成该任务的能力。受控英语可以降低表达上的歧义但不能替代模型对任务的理解能力。第五步看任务目标是否真的可判定。如果任务目标是模糊的受控英语只会让模糊目标以更规范的形式出现并不会让目标变清晰。这时候需要回到任务设计阶段重新拆解目标。6.2 建立一套简单的协议合规检查机制受控英语体系想要长期稳定运行不能只靠“所有 Agent 都自觉遵守约定”。建议在系统里增加一个轻量级的合规检查步骤每次 Agent 通信前或通信后进行格式校验。这个校验可以很简单字段名是否在约定表内状态值是否在合法枚举内必要字段是否缺失数据引用是否可以解析到实际文件上游状态是否符合当前任务的执行条件。这些校验逻辑用代码实现并不复杂但它能把受控英语从“写作规范”变成“系统约束”。只有到了这一步受控英语才算真正落地而不仅仅是一份文档。7. 回到本源Canon-A 这类方案真正改变的协作方式7.1 从“让 AI 听懂”到“让我们和 AI 之间达成协议”过去几年提示词工程的核心叙事一直是“如何让 AI 听懂人话”。我们研究措辞、研究上下文、研究 few-shot都是在帮助模型更好地理解人类意图。但 Canon-A 所代表的受控英语思路把这个问题往前推了一步与其花大量精力让模型猜测我们的意图不如定义一套双方都遵守的表达边界。这不是说自然语言提示不重要了而是在“自由表达”和“稳定执行”之间找到一个更适合系统化协作的平衡点。这件事对普通开发者来说意味着提示词不再是放在单个对话框里的临时文本而是一套需要设计、审查、维护的接口规范。7.2 单 Agent 时代靠技巧多 Agent 时代靠协议在单 Agent 阶段你可以靠技巧取胜。调整 prompt、换模型、加 RAG每一点改进都能看到效果。但当你进入多 Agent 或者复杂工作流阶段单个调优带来的边际收益会越来越小系统整体的稳定性会成为主要瓶颈。这时候真正的杠杆点不是“让某个 Agent 更聪明”而是“让 Agent 之间的通信更可控”。受控英语不是唯一的解决方案甚至不一定是最优方案。但它包含了一个重要判断系统的可靠性不只取决于每个组件的能力更取决于组件之间用什么语言交流。这个判断对整个 Agent 开发方向都有长期参考价值。7.3 我的建议先跑通再受控最后协议化如果你看完这篇文章想尝试 Canon-A 或类似的受控英语思路我的建议是分三步走。第一步先用自然语言把整条任务链路跑通确定业务逻辑本身没有问题。第二步把链路中 Agent 之间交换的信息逐一列出来找出其中最容易产生歧义的状态词、指令和字段先用固定的枚举值和结构化格式把它们约束住。第三步再考虑引入更完整的受控英语规范并配上合规检查机制。不要一上来就追求“完全受控”。受控英语的价值是在正确的时间、正确的环节用正确的方式被引入。它的核心目标从来不是“让表达更好看”而是“让协作更可靠”。当你把它放在这个位置上看它就不再是一个单纯的提示词技巧而是一条从“调模型”走向“设计系统”的路径。