TL;DR

问题背景

我们团队在构建AI Agent编排系统时，遇到了一个看似简单却棘手的问题：Agent的工作流描述需要在多个语言版本间保持同步。在系统初期，我们采用"并行维护"策略——每个语言版本独立维护一份完整的工作流配置。结果仅维护3种语言（中文、英文、日文），每月的Token消耗就突破了800万，而且每次工作流逻辑调整，都需要同步修改3份配置文件，漏改率高达40%。

为什么这个决策难做

我们一开始以为这个问题是"翻译成本高"，所以投入了精力去优化翻译流程、引入更便宜的翻译服务。但实际上，真正的瓶颈不在翻译价格，而在于信息分散导致的维护成本。

具体来说，当工作流描述分散在多个独立文件中时，存在三个致命问题：其一，修改一处可能遗漏其他语言版本；其二，各语言版本的注释和表述存在细微差异，导致Agent对同一工作流的理解产生偏差；其三，回滚操作需要分别处理多个文件，极易出现版本不一致。这种"看似灵活"的分布式架构，实际上成了维护的噩梦。

根因分析与核心设计决策

经过排查，我们发现问题的根因是缺乏单一信息源（Single Source of Truth）。于是我们重新设计了工作流知识管理的架构：

# 工作流源文件 design/workflows/checkout.yml
name: checkout_flow
description: 订单结算工作流
steps:


id: validate
type: validation
prompt_template: |
验证订单 {order_id} 的状态是否为 pending，
返回 {is_valid: true/false}


id: payment
type: payment
prompt_template: |
调用支付接口完成扣款，
金额: {amount} {currency}


i18n 层输出示例：generate-i18n.sh
for lang in zh en ja; do
python scripts/translate.py 

—source workflows/checkout.yml 

—target locales/$lang/checkout.yml 

—locale $lang
done

核心思路是：业务逻辑层只维护一份源文件（YAML格式），通过脚本自动生成各语言版本。翻译不再是"同步修改"，而是"派生生成"——修改源文件后，触发翻译流水线，各语言版本自动更新。

这个设计带来了两个关键变化：首先，Token消耗从"全量维护"变成"增量翻译"，每次修改只翻译变更部分；其次，质量管控从"事后检查"变成"源头控制"，只需要保证源文件的准确性。

可移植的原则

1. 如果你在构建多语言AI工作流系统，优先设计SSOT架构，让所有语言版本从单一源文件派生，而非独立维护。
2. 如果你需要降低Token消耗，把翻译流水线接入CI/CD，改为增量翻译而非全量翻译，覆盖范围按需扩展。
3. 如果你担心翻译质量失控，使用结构化的源文件格式（如YAML/JSON），而非自然语言文档，便于机器翻译解析。
4. 如果你面临版本回滚需求，确保回滚操作是原子性的，所有语言版本同步回滚至同一基准版本。

结尾

SSOT+i18n策略的核心价值，在于将"维护多份副本"转变为"维护一份源+派生流程"。这个改变不依赖任何特定工具，核心是信息流的设计思路。如果你正在为AI工作流的多语言管理头疼，不妨先审视当前的信息架构——也许问题的答案，不在于更贵的翻译服务，而在于重新组织信息的组织方式。