实验 10-2 豆包版复现分析书籍翻译 Agent 的管理者模式一、实验概述实验 10-2 用管理者模式Orchestration把一本英文技术小书的翻译拆给四个专职 AgentGlossary抽术语表→ Translation逐章翻译每章一个独立实例→ Proofreading审校→Manager调度与决策。核心主张是上下文隔离与控制 Manager 上下文膨胀完整译文全部落盘Manager 上下文里只留任务、计划、调用记录与文件路径因此书越长、Manager 上下文基本不涨。对照组是「单 Agent 一条持续增长的对话翻完整本书」用来量化两者在上下文峰值、术语一致性和成本上的差别。本实验的原版默认走 OpenAI / OpenRouter。本次复现改用火山方舟 Coding PlanOpenAI 兼容端点/api/coding/v3以验证该书实验在国产订阅套餐上的可复现性。二、运行配置配置项值Providerark-coding本次新增见第三节端点https://ark.cn-beijing.volces.com/api/coding/v3OpenAI 兼容模型deepseek-v4.1-flash凭据Coding Plan 专属ARK_API_KEY来自.env值不落盘、本文不回显思考开关请求体显式thinking{type:disabled}翻译方向英文 → 中文语料sample_book/4 个短章节运行方式管理者模式 单 Agent 对照未加--skip-single运行时间2026-10-01deepseek-v4.1-flash属方舟 Coding Plan 套餐内模型本次翻译链路与审校/调度调用均走该端点。三、复现改造点相对原版原代码只有 OpenAI / OpenRouter / Mistral / 方舟标准 API 几条路径。本次为跑通 Coding Plan 做了如下改动agents.py新增ark-codingproviderBase URL 指向…/api/coding/v3Key 取ARK_CODING_API_KEY缺省回退ARK_API_KEY模型缺省deepseek-v4.1-flash可用ARK_CODING_MODEL/OPENAI_MODEL/--model覆盖。抽出THINKING_DISABLED_PROVIDERS常量把原先硬编码的「方舟需要关思考」逻辑收敛为一处避免推理占满 completion 导致译文正文为空ark-coding一并纳入。demo.py新增--provider参数并修正原有的 Key 校验——原实现只认OPENAI_API_KEY/OPENROUTER_API_KEY会把ark/ark-coding误拦在门外。demo.py显式加载脚本同目录.envload_dotenv(os.path.join(HERE, .env))保证从任意工作目录运行都能读到配置。run_official_experiment.py的--provider增加ark-coding并同步其 thinking 口径。改造后的链路与协议语义未变四角色、文件系统传参、共享术语表、确定性字符串匹配统计全部沿用原设计。四、实测结果指标管理者模式单 Agent来源主/Manager 上下文峰值 (tokens)10222050控制台Manager LLM 决策调用上下文 (tokens)751—控制台全流程总 token74925948管理者控制台单 Agent可复算术语内部一致率100% (9/9)88.9% (8/9)可复算指定术语遵从率100% (15/15)26.7% (4/15)可复算参与 Agent 种类数41代码结构单 Agent 的 token 明细可从output/single_agent/progress.json逐调用复算真实 API usage调用输入 (prompt)输出 (completion)Chapter 1368299Chapter 2944252Chapter 31482263Chapter 42050290合计48441104注单 Agent 第 4 章的输入 2050 即「主上下文峰值」——它随章节线性累积368 → 944 → 1482 → 2050每翻一章就把前面所有章节的译文和输出重新塞回上下文。管理者模式没有这个累积过程Manager 的峰值 1022 主要由术语表与调用记录构成与每章正文长度无关。五、术语一致性实测明细管理者模式把「编辑部指定术语」强制写进共享术语表下发给每个 Translation 实例。指定术语规定 / 默认出现命中token词元 / 标记44prompt提示词 / 提示44latency时延 / 延迟44embedding嵌入向量 / 嵌入33内部一致率 9/99 个被追踪术语词元、提示词、时延、嵌入向量、推理、注意力、Transformer、吞吐量、微调在各自出现的章节里均只用单一译法无跨章漂移。单 Agent同样的译文但看不到术语表。指定术语规定 / 默认出现命中单 Agent 实际用的写法token词元 / 标记44词元自发命中prompt提示词 / 提示40提示4 章latency时延 / 延迟40延迟4 章embedding嵌入向量 / 嵌入30嵌入3 章内部一致率 8/9唯一不一致的是token——全书同时出现「词元」4 章与英文token2 章正文非代码块两种写法属典型的跨章漂移。共享术语表收录 12 条4 条强制指定 Glossary Agent 自动抽取 8 条token→词元、embedding→嵌入向量、prompt→提示词、inference→推理、latency→时延、transformer→Transformer、attention→注意力、throughput→吞吐量、KV cache→KV缓存、batching→批处理、fine-tuning→微调、deployment→部署。六、审校报告proofreading_report.json共报5 条问题chapters_need_revision列出全部 4 章术语类 4 条Ch1 token、Ch2 attention、Ch3 KV cache、Ch4 fine-tuning——均指向代码注释 / 变量名里仍保留英文原文流畅性 1 条Chapter 4 标题的数字与冒号之间有多余空格。报告总结整体术语基本一致但代码内仍保留英文术语建议统一并修正标题空格。这不与「管理者模式遵从率 100%」矛盾consistency.py统计前会_strip_code去掉围栏代码与行内代码遵从率衡量的是正文表述代码注释保留英文正是翻译指南的预期行为。审校 Agent 额外把这一层作为「可选优化」报了出来——说明四角色分工里审校确实在做独立于术语表的检查。七、分析与结论上下文隔离成立但幅度比 README 样本小。本次 Manager 峰值 1022 vs 单 Agent 2050约2.0 倍README 记录的 gpt-5.6-luna 运行是 697 vs 23203.3 倍。差距缩小的直接原因是单 Agent 的累积起点更低368 tokens且每章输出更短~270 completion。关键不在这一个倍数而在增长曲线的形状单 Agent 是 368→944→1482→2050 的线性累积管理者模式的 Manager 状态只随「章节数」增加一行记录与每章正文长度无关——书越长差距越大。共享术语表把「指定译法」从可选变成强制。管理者模式 15/15 全中单 Agent 只有 4/15。值得注意的是单 Agent 在 token 上自发采用了与规定一致的「词元」4/4但对没有唯一标准的术语各行其是——prompt 一律译「提示」、latency 一律译「延迟」、embedding 一律译「嵌入」三者在全书内各自一致却不合规定。这正好说明单 Agent 的问题不是乱翻而是无人裁决。单 Agent 的真实缺陷是跨章漂移而非译法不同。它的 88.9% 内部一致率唯一失分项就是token4 章写「词元」、2 章正文写token。同一个术语在同一本书里换写法是长文档翻译最典型的质量事故管理者模式靠「一份术语表下发所有 Translation 实例」从机制上消除了它。代价方向与 README 一致管理者模式更贵。总 token 7492 vs 594826%多出来的部分花在术语表抽取、审校和调度决策上。换来的是可控的主上下文与可强制的术语统一——对长文档翻译而言这两个性质比省 token 重要。一次诚实的负结果四角色跑完后审校 Agent 仍然报了 5 条问题、4 章全部进了待修订列表。即「共享术语表 一轮审校」并不能让所有检查项归零——术语表管的是正文表述代码注释、标题格式这类问题需要另外的规则。管理者的价值是把这些问题显式暴露成结构化报告并决定是否回退修订而不是假装没有。八、局限与注意事项语料只有4 个短章节用于暴露机制不代表大规模真实书籍的绝对 token 数值。管理者模式的 token/上下文数值1022 / 751 / 7492只在控制台打印、未落盘无法离线复核单 Agent 的数值已从progress.json逐调用复算。建议后续给管理者模式也加一份 metrics 落盘。术语指标为确定性字符串匹配consistency.py不是模型自评可能漏判更灵活的措辞变体。单次运行的数字会随模型输出随机性小幅波动量级与结论稳定。合规提示火山方舟官方文档明确说明 Coding Plan 套餐额度仅在 AI 编程工具中生效、不可用于API 调用在非编程工具中使用其专属 Base URL Key 有可能被识别为滥用/违规。本次运行是把Coding Plan 当作可选 provider 做的技术验证生产用途请改用方舟标准 API 或其它正规计费通道且切勿混用平台ARK_API_KEY与 Coding Plan 专属 Key。附录本次运行产物清单文件字节output/orchestration/chapter1_zh.md1340output/orchestration/chapter2_zh.md1234output/orchestration/chapter3_zh.md1138output/orchestration/chapter4_zh.md1273output/orchestration/glossary.json2026output/orchestration/proofreading_report.json1670output/single_agent/chapter1_zh.md1371output/single_agent/chapter2_zh.md1269output/single_agent/chapter3_zh.md1234output/single_agent/chapter4_zh.md1333output/single_agent/progress.json7096两组均产出 4 篇译文每篇 1 个 H1 标题 1 个代码块管理者模式各篇体积略小。复现命令# 仓库根目录构建第 10 章环境含 dev 依赖便于跑离线测试uv sync--locked--python 3.12--extra ch10--extra dev cd chapter10/book-translation# 离线自检不联网、不消耗额度.\.venv\Scripts\python.exe demo.py--dry-run.\.venv\Scripts\python.exe-m pytest tests-q# 14 passed# 管理者模式 单 Agent 对照真实调用需 ARK_API_KEY消耗套餐额度.\.venv\Scripts\python.exe demo.py# 只跑管理者模式调用更少.\.venv\Scripts\python.exe demo.py--skip-single.env关键项LLM_PROVIDERark-coding、ARK_API_KEYCoding Plan 专属 Key、ARK_CODING_MODELdeepseek-v4.1-flash.env已被 gitignore。