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 数量的收益。