Plawan Rath、Akhil Jindal、Ashwini Verma / Meta Engineering · 阅读原文
原始来源：Plawan Rath、Akhil Jindal、Ashwini Verma / Meta Engineering
发现渠道：AIHOT
Meta 这篇工程记录讨论的是推荐系统的数据列接入：新增一个字段后，要让它从配置定义、生成代码一路进入处理服务和分析系统。这里的配置本身也是代码，Python 配置会驱动 C++ 代码生成；一列数据最多经过六个阶段，修改涉及三个仓库、三种语言。只改好其中一个文件，不能保证上下游仍把它当作同一种数据处理。
旧方案把配置结构、命名规则、生成代码的方法和十多种数据源的填充方式都放进同一个 Agent。生产中出现的错误很具体：把一个子系统的字段命名惯例套到另一个子系统，或者用数据源 A 的生成模式处理数据源 B。团队认为，知识全放在一起反而增加了规则混用的机会，因而把流程控制和领域推理拆开。
新的固定编排器约 1,300 行，只负责顺序和检查。每次请求先读取对应专门 Agent 的说明，确认目标是否已存在，向用户收齐必需字段，自动查找仓库类型与已有配置，再检查警告和所需审核人；这些条件齐备后才派发任务，最后接收结果、报告错误或确认完成。真正解释配置与修改代码的是 14 个专门 Agent：例如 schema（结构定义）Agent 管配置注册，population（数据填充）Agent 管按数据源生成代码，validation（验证）Agent 管构建与质量检查。它们执行时只加载所需的领域知识，而非共享全部上下文。
专业 Agent 的协作顺序由工作流模板规定。原文的数据列接入依次经过定义、验证、填充、测试；事件接入还要增加事件处理；迁移则先评估与规划，再复用已有 Agent 完成后续步骤。这样，新增工作流可以改变组合顺序，而不必再造一组角色。知识也独立存放，更新知识文件即可供下一次执行读取。
作者报告，单列配置准备从人工三四天、早期配置驱动系统约一天，缩至一小时以内；约三分之二的改动无需重大人工修改。另一个单 Agent 方案在工程师逐任务精写提示时成功率为 70%—80%，没有这种辅助时为 10%—20%。这些是不同工作方式的内部经验比较，提示准备、人力与流程同时变化，不能把差额全算成增加 Agent 数量的收益。
可信度 65 · 重要性 85 · 新颖度 78
技术与主题
编辑评读
这套设计的贡献，是让错误能够落到具体环节。以重复接入为例，目标是否已存在可以在派发前核对；以命名规则混用为例，则需要缩小专门 Agent 能看到的规则范围。两种故障有不同修复办法。把它们都交给一个更长的系统提示，会让维护者难以判断是流程漏做，还是模型读错了领域条件。原文给出的七步协议和工作流模板，使这种区分有了可维护的落点。
值得借鉴的还有复用单位的变化。新增迁移任务时复用 schema、population 等能力，只调整阶段顺序，意味着团队维护的是一组有明确输入和职责的步骤。知识文件更新与编排代码分开，也减少了每次修规则都要改路由的牵连。不过，这要求领域边界足够清楚；若两个步骤必须共同决定某个约束，就需要显式传递该约束，隔离上下文本身不会保证它们达成一致。
因此，迁移这套方法时，可以先找流程中已经稳定的前置条件和交付物，再决定哪些判断交给模型。原文的时间下降支持它在这一成熟数据流水线中的实用价值；约三分之一改动仍需较大人工修改，则提示接下来应看返工集中在哪些领域、由谁补足。对需求仍在探索的工作，固定模板也应允许退回澄清，否则只是更快地执行了一个尚未说清的流程。
需要留意
- 企业内部经验；缺少随机化、同预算的独立对照。后续反馈机制仍属计划。