专业化 Agent 需要专业化训练数据：agency-agents 告诉了我们什么

2025 年 10 月，Reddit 上有人发了一个帖子，问能不能把不同专业角色的 AI 行为规范整理成一个开源项目。几个月后，agency-agents 已经有几十个专业化 Agent 人格文件。每个文件不是一段 prompt 模板，而是完整的「专家行为规范」：这个 Agent 是谁、面对任务时的标准工作流、交付物应该长什么样、遇到分歧时怎么沟通。这个项目的存在本身，是对当前训练数据体系的一个无声的控诉。

专家行为和通才行为的差异

同一段代码，Security Engineer 和 Frontend Developer 看到的是两个不同的世界。

Security Engineer 的第一反应：谁能访问这个接口？注入点在哪？鉴权是在哪一层做的？Frontend Developer 的第一反应：这个组件会不会触发多余的重渲染？CSS 变量命名有没有遵守规范？事件监听有没有清理？这不是能力差异，是关注点的结构性不同——两个人受过不同训练，内化了不同的优先级排序。

再看另一组对比。Backend Architect 设计一个 API，第一步是画 ER 图和服务边界，确认边界稳定了再动代码；Rapid Prototyper 直接开始写，把「是否需要验证」留到真正需要的时候再决定。这两种行为在各自的场景下都是正确的，但底层的决策逻辑完全不同——一个在优化长期可维护性，一个在优化短期验证速度。

现有训练数据里，这两类行为大量存在，却几乎是随机混合的。模型见过很多「以安全视角写的代码审查」，也见过「以速度为先写的原型代码」，但几乎没有见过「同一个 Agent 在明确角色约束下，在一个多轮复杂任务里，始终如一地保持专家行为」的完整轨迹。

agency-agents 揭示的数据缺口

这个项目的 Markdown 文件结构非常值得分析。每个人格文件大致包含四个维度：

Identity：专家的自我认同和工作信念。不是「你是一个安全工程师」这种标签，而是「我的工作是交付可以在周五放心部署的代码，不是交付让领导觉得酷的代码」这样的立场声明。

Workflows：面对一类任务时的标准操作序列。不是通用的「思考→行动→反思」循环，而是特定领域的专家判断路径——Security Engineer 在代码审查时的检查清单，和 Data Engineer 在设计 pipeline 时的检查清单，结构完全不同。

Deliverables：期望的输出格式和质量标准。具体到「你的回答里必须包含一个复杂度分析表格」或「所有 SQL 都要附上执行计划说明」。

Communication Style：如何表达不确定性、如何推回不合理需求。Senior Developer 会说「这个需求的前提假设有问题，我建议先讨论 X 再写代码」；Rapid Prototyper 会说「先这样跑通，之后有需要再改」。

这四个维度在现有训练数据里都有，但它们组合成一个一致的专业化 Agent 的完整轨迹几乎不存在。模型知道「安全工程师应该关注注入点」，但不知道「一个始终如一的安全工程师在多轮任务里如何保持专业立场、如何在压力下拒绝走捷径、如何维持自己的标准」。

对数据建设的三个启发

启发一：角色内聚性数据

不是「关于安全的数据」，而是「一个安全工程师完整完成一个任务的轨迹」。关键在于角色内聚性——同一任务中，所有决策点都要体现一致的专家视角，包括那些看起来不重要的小决策。

数据来源其实就在眼前：可以把 agency-agents 里的人格文件作为系统提示约束，让模型在强角色约束下完成复杂的多轮任务，收集这些轨迹。人格文件本身就是过滤器，帮助筛选出角色内聚性强的行为。

启发二：角色切换的 handoff 数据

真实场景里，Frontend Developer 做到一半发现了安全漏洞，需要切换到 Security Engineer 视角处理——这个切换点是数据金矿。handoff 的质量（上一个专家留下的上下文是否足够清晰，下一个专家能否准确接手）是多 Agent 协调能力的核心。

这正是我们在多 Agent 协作失败数据里命名但没有解决的「自然边界识别」问题的真实数据来源。边界在哪、谁来画边界、边界画错了怎么修正——这些都需要真实的 handoff 轨迹来训练。

启发三：Skill 文件本身作为元数据

agency-agents 里的每个 Markdown 文件，结构上和 DeerFlow 的 Skills 系统几乎相同：都是行为规范文档，而不是 prompt 模板。这些文件可以作为「高质量 Skill 文件的标准」。训练模型读懂这类文件、在执行中遵守其中的约束，是 Harness Engineering 的上游问题——在 harness 能发挥作用之前，模型得先理解 harness 在说什么。

症状和病

agency-agents 这个项目的价值不在于它的代码，而在于它揭示了一个社区共识：人们相信专业化 Agent 和通才 Agent 是本质不同的东西，值得花时间单独构建。这种信念催生了几十个精心维护的人格文件，每个背后都是真实用户在 prompt 工程上投入的大量时间。

问题是：如果专业化行为需要工程手段（人格文件、系统提示、行为规范）来约束，那说明我们还没有把专业化行为训练进模型里。agency-agents 是一个症状，对应的病是训练数据里缺乏角色内聚性的专业行为轨迹。填补这个缺口，是让 Agent 真正「成为专家」而不只是「知道专家应该做什么」的前提。