268 个 AI 专家角色怎么用：Agency Agents 中文版的 Codex 实战手册

一句话摘要：把 268 个角色当作可按需调用的“专业工作说明书”——先选对角色，再给清输入、边界和验收标准，最后用审查角色复核结果。

目录

一、先说结论：它不是 268 个聊天机器人

agency-agents-zh 是一套角色定义库。每个角色都带有专业身份、工作流程、关注重点和预期交付物；它的价值不是让模型“扮演得更像”，而是把任务的思考框架、检查项和输出格式前置。

对我自己最实用的用法是：把它当作任务路由表。遇到需求、设计、开发、测试、上线或运营问题时，先问“这件事最终需要哪一种专业判断”，再点名对应角色，而不是把所有问题都交给泛化的“帮我做一下”。

本地已验证的安装结果如下：

项目	结果
角色总数	268 个
分类	19 个部门
Codex 文件格式	TOML
当前项目安装位置	.codex/agents/
调用原则	在任务中明确写出角色 ID 和要完成的交付物

[!IMPORTANT]
这套配置是项目级的。切换到另一个项目时，需要在新项目根目录再执行一次安装，不能假设它会自动全局生效。

二、三分钟开始：安装、确认和第一次调用

1. 安装到 Codex 项目

在仓库目录先转换，然后进入目标项目执行安装：

cd /Users/xiaoxiangyuan/.codex/agency-agents-zh
bash scripts/convert.sh --tool codex

cd /你的项目目录
bash /Users/xiaoxiangyuan/.codex/agency-agents-zh/scripts/install.sh --tool codex

成功后，项目下应有 .codex/agents/，其中包含 268 个 .toml 文件。可以这样检查：

find .codex/agents -maxdepth 1 -name '*.toml' | wc -l
# 预期输出：268

2. 最小调用示例

在 Codex 的任务描述中，直接写明角色 ID、上下文、目标和验收条件：

请使用 engineering-frontend-developer 子代理处理当前项目。

上下文：订单列表页在移动端横向溢出。
目标：修复布局且不改变桌面端表格字段。
约束：只改前端相关文件；保持现有 Ant Design 风格。
验收：375px 宽度不出现横向页面滚动，并给出实际验证结果。

比起“帮我修一下页面”，这个提示明确了四件事：谁来做、看什么上下文、交付什么、什么算完成。角色负责专业方法，任务描述负责业务事实；两者缺一不可。

3. 当前 Codex 的调用边界

仓库说明这些配置会作为 subagent 使用。当前 CLI 帮助中没有公开的 --agent 手动选择参数，因此最稳妥的方式是在任务里点名完整角色 ID，并要求其按该角色的职责工作。不要把角色名只写成“前端专家”，否则无法保证使用的是你期望的那一份配置。

三、选角色的正确方法：按“交付物”而非按“职位”

常用角色中英对照

以下是日常开发、内容和上线工作里最常用的一组。实际调用时复制第三列的角色 ID 即可。

中文角色	English role	角色 ID
前端开发者	Frontend Developer	engineering-frontend-developer
后端架构师	Backend Architect	engineering-backend-architect
UI 设计师	UI Designer	design-ui-designer
产品经理	Product Manager	product-manager
代码审查员	Code Reviewer	engineering-code-reviewer
DevOps 自动化师	DevOps Automator	engineering-devops-automator
SRE（站点可靠性工程师）	Site Reliability Engineer	engineering-sre
应用安全工程师	Application Security Engineer	security-appsec-engineer
API 测试员	API Tester	testing-api-tester
技术文档工程师	Technical Writer	engineering-technical-writer
内容创作者	Content Creator	marketing-content-creator
小红书运营专家	Xiaohongshu Operator	marketing-xiaohongshu-operator

1. 一张决策图

读图要点：第一个角色负责产出，第二个角色负责挑战、验证或补足盲区。复杂任务不要让所有角色并发“各写一遍答案”，而要让它们在清晰的交接点上接力。

2. 四步选人法

步骤	要问的问题	例子
定义产物	最终交付是代码、方案、报告还是内容？	要 API 设计，先选后端架构师
找主责	谁对这个产物最专业？	要小红书投放，选小红书运营专家
找制衡	最容易遗漏什么？	上线前再找 AppSec、API 测试员
控制人数	是否真的存在独立工作流？	小改动只用 1 个角色；跨端功能用 2—4 个

[!TIP]
角色越具体越好。需要优化 PostgreSQL 查询时优先 engineering-database-optimizer，而不是宽泛的 engineering-backend-architect；需要排查线上故障则优先 engineering-incident-response-commander，不是泛化的 DevOps。

3. 可复用的提示词模板

请使用 <agent-id> 子代理处理此任务。

业务背景：<为什么要做，相关用户或系统是什么>
已有事实：<文件、接口、数据、现象或链接>
目标交付：<代码 / 方案 / 清单 / 报告>
不做什么：<明确排除项，避免范围膨胀>
约束：<技术栈、时间、合规、预算、风格>
验收标准：<可观察、可验证的完成条件>

如果只是咨询，把“目标交付”替换为“请先给出判断依据、备选方案和风险，不执行修改”。如果要执行，则要求它先检查现状、最小化修改并报告验证证据。

四、四个高频实战场景

场景一：交付一个前后端功能

角色链： product-manager → engineering-backend-architect / engineering-frontend-developer → testing-api-tester → security-appsec-engineer。

不要让四个角色同时“实现功能”。正确做法是：产品经理先把验收标准写清；前后端各自在明确接口下实施；测试员验证功能；安全角色只审查真正涉及认证、授权、输入、敏感数据或外部暴露面的部分。

场景二：修复线上故障

首选 engineering-incident-response-commander 组织处置，配合 engineering-sre 看监控和可靠性，根因落到代码或数据层时再交给 engineering-backend-architect、engineering-database-optimizer 或 engineering-ai-data-remediation-engineer。

提示词要包含：开始时间、影响范围、错误现象、已经做过的操作，以及“先止血还是先根治”的优先级。不要把生产日志、Token、Cookie 或用户隐私直接粘贴进任务。

场景三：把一个主题做成 CSDN / 小红书内容

先用 marketing-content-creator 或 engineering-technical-writer 形成主稿；CSDN 偏技术教程、可复现和代码说明，随后可交给 marketing-multi-platform-publisher 改造成多平台草稿。若是小红书，再交给 marketing-xiaohongshu-operator 处理选题、标题、笔记结构和互动策略。

[!WARNING]
内容角色可以生成草稿、配图建议和发布清单，但真实发布、账号授权和商业承诺必须由人确认。尤其是医疗、金融、法律和投放内容，要再经过对应合规角色审核。

场景四：做一次安全或质量上线门禁

普通 Web/API 上线可采用：testing-api-tester + testing-performance-benchmarker + testing-accessibility-auditor + security-appsec-engineer。有云权限、合规认证或事故时，再分别引入 security-cloud-security-architect、security-compliance-auditor、security-incident-responder。

要求每个角色输出“发现项、证据、风险等级、修复建议、是否阻塞上线”，不要只收一句“看起来没问题”。

五、避免角色库失效的五条规则

1. 一个任务只设一个主责角色。 多个角色都能回答，不代表多个角色都该做同一件事。
2. 输入只给必要事实。 角色定义不能替代项目上下文；但也不要把整仓库、密钥或无关聊天记录塞给它。
3. 把“交付格式”写出来。 例如要求表格、接口草案、风险清单、补丁或测试命令。
4. 让独立角色验收。 实现者不应是唯一验收者；代码由测试、安全或审查角色挑战更可靠。
5. 对高风险专业结论保留人工责任。 法务、医疗、投资、税务、支付和生产变更只能作为辅助分析，不能替代持证意见、审批或人工发布。

六、268 个角色全量速查表

下面按部门列出全部角色。使用时，优先按中文职责找到候选项，再在任务中填写对应的角色 ID；角色 ID 就是安装后 .codex/agents/ 目录中 TOML 文件的文件名（不带扩展名）。完整的“中文名 → 源文件路径”映射见项目的 CATALOG.md：例如 engineering/engineering-software-architect.md 对应 engineering-software-architect。

学术部（6）

角色	典型用途
人类学家	世界观、文化体系、社会习俗设定
地理学家	地形、气候、资源与空间合理性
历史学家	历史题材考据和时代一致性
叙事学家	故事结构、人物弧线和剧情分析
心理学家	动机、行为和心理可信度
学习规划师	考试、技能学习和周期计划

设计部（9）

Persona 走查专家、品牌守护者、图像提示词工程师、包容性视觉专家、UI 设计师、UX 架构师、UX 研究员、视觉叙事师、趣味注入师。

适用任务：界面设计与走查、设计系统、用户研究、品牌一致性、AI 绘图提示词、信息图和无障碍视觉审查。

工程部（42）

Drupal 购物车工程师、IT 服务经理、多智能体系统架构师、OrgScript 工程师、Prompt 工程师、WordPress 购物车工程师、AI 数据修复工程师、AI 工程师、自主优化架构师、后端架构师、CMS 开发者、代码库入职引导工程师、代码审查员、数据工程师、邮件智能工程师、数据库优化师、DevOps 自动化师、钉钉集成开发工程师、嵌入式固件工程师、上位机工程师、Filament 优化专家、嵌入式 Linux 驱动工程师、飞书集成开发工程师、FPGA/ASIC 数字设计工程师、前端开发者、Git 工作流大师、机械设计工程师、故障响应指挥官、IoT 方案架构师、最小变更工程师、移动应用开发者、快速原型师、安全工程师、高级开发者、软件架构师、Solidity 智能合约工程师、SRE (站点可靠性工程师)、技术文档工程师、威胁检测工程师（工程侧）、语音 AI 集成工程师、国内网络工程师、微信小程序开发者。

选择口诀：做页面找前端，做接口找后端，做数据找数据工程与数据库优化，做部署找 DevOps/SRE，做事故找故障响应指挥官，做代码审查找代码审查员或最小变更工程师。

金融部（9）

香港股市合规审查专家、簿记与财务总监、财务分析师、财务预测分析师、FP&A 分析师、金融风控分析师、投资研究员、发票管理专家、税务策略师。

适用任务：记账、预算、现金流预测、投资研究、支付反欺诈、发票流转和税务方案。所有结论均需人工、财务或法务复核。

游戏开发部（20）

Blender 插件工程师、游戏音频工程师、游戏设计师、Godot 游戏脚本开发者、Godot 多人游戏工程师、Godot Shader 开发者、关卡设计师、叙事设计师、Roblox 虚拟形象创作者、Roblox 体验设计师、Roblox 系统脚本工程师、技术美术、Unity 架构师、Unity 编辑器工具开发者、Unity 多人游戏工程师、Unity Shader Graph 美术师、Unreal 多人游戏架构师、Unreal 系统工程师、Unreal 技术美术、Unreal 世界构建师。

按引擎和产物选择：玩法与关卡找设计角色，联网找多人角色，材质和资源管线找 Shader/技术美术，工具链找编辑器或插件角色。

人力资源部（2）与法务部（2）

绩效管理专家、招聘专家（HR 全流程）；合同审查专家、制度文件撰写专家。

适用任务：招聘流程、绩效体系、合同风险清单、隐私和制度文档草案。它们用于准备材料和发现风险，不替代正式法律意见。

营销部（42）

AEO 基础架构师、邮件营销策略师、全球播客策略师、多平台发布编排官、PR 与传播经理、X/Twitter 情报分析师、智能搜索优化师、AI 引文策略师、应用商店优化师、百度 SEO 专家、B站内容策略师、图书联合作者、轮播图增长引擎、中国市场本地化策略师、新闻情报官、中国电商运营专家、内容创作者、跨境电商运营专家、抖音策略师、电商运营师、增长黑客、Instagram 策展师、知识付费产品策划师、快手策略师、LinkedIn 内容创作专家、直播电商主播教练、播客内容策略师、私域流量运营师、Reddit 社区运营、SEO专家、短视频剪辑指导师、社交媒体策略师、TikTok 策略师、视频优化专家、Twitter 互动官、微信公众号管理、微信公众号运营、微博运营策略师、微信视频号运营策略师、小红书运营专家、小红书专家、知乎策略师。

使用原则：先按平台选人，再按目标选人。要做小红书种草优先“小红书运营专家”；要做 SEO 再区分百度、通用 SEO、AEO、AI 引文或智能体搜索优化；要跨平台发布则让“多平台发布编排官”先产出草稿和渠道差异表。

付费媒体部（7）

付费媒体审计师、广告创意策略师、社交广告策略师、PPC 竞价策略师、程序化广告采买专家、搜索词分析师、追踪与归因专家。

分别用于账户体检、素材测试、社媒广告、搜索竞价、程序化投放、搜索词优化和埋点归因。涉及真实预算调整前，必须人工确认账户、金额、时段和止损线。

产品部（5）与项目管理部（7）

产品部：行为助推引擎、反馈分析师、产品经理、Sprint 排序师、趋势研究员。

项目管理部：会议纪要专家、实验追踪员、Jira工作流管家、项目牧羊人、工作室运营、工作室制片人、高级项目经理。

产品角色用来回答“做什么、为什么现在做”；项目角色用来回答“谁在什么时候以什么节奏交付”。两者一起使用时，先定优先级，再拆计划和跟踪执行。

销售部（9）

Offer 与 Lead Gen 策略师、客户拓展策略师、销售教练、赢单策略师、Discovery 教练、售前工程师、Outbound 策略师、Pipeline 分析师、投标策略师。

从漏斗前端到成交：Offer/Lead Gen 做获客，Outbound 做触达，Discovery 做需求诊断，售前工程师做 Demo/POC，赢单和投标策略师处理复杂机会，Pipeline 分析师和销售教练负责过程改进。

空间计算部（6）

macOS Metal 空间工程师、终端集成专家、visionOS 空间工程师、XR 座舱交互专家、XR 沉浸式开发者、XR 界面架构师。

对应 Metal、终端渲染、visionOS、车载 XR、WebXR/沉浸式应用和空间交互架构。先按目标平台选择，再补 UI 或图形管线角色。

专项部（58）

商业战略家、变革管理顾问、首席财务官、客户成功经理、数据隐私官、ESG 与可持续发展官、资助申请撰稿人、M&A 整合经理、医疗账单与编码专员、运营经理、组织心理学家、个人成长导师、定价分析师、策略对决推演师、应付账款智能体、身份信任架构师、智能体编排者、自动化治理架构师、养殖档案核对员、土木工程师、企业培训课程设计师、数据整合师、高考志愿填报顾问、政务数字化售前顾问、医疗客服专家、医疗健康营销合规师、酒店宾客服务专家、HR 入职管理专家、身份图谱操作员、语言翻译专家、律所计费与工时专家、律所客户接案专家、法律文书审查专家、信贷经理助手、LSP 索引工程师、提示词工程师、人才获取专家、报告分发师、销售数据提取师、AI 治理政策专家、文化智能策略师、开发者布道师、文档生成器、法国咨询市场专家、韩国商务专家、MCP 构建器、会议效率专家、模型 QA 专家、动态定价策略师、房地产经纪助手、零售退货专家、企业风险评估师、Salesforce 架构师、工作流架构师、幕僚长、留学规划顾问、技术翻译专家、ZK 管家。

专项部的选择方法很简单：当任务有明显行业、地区、合规或组织管理属性时，优先在这里找更窄的角色；例如做 MCP 服务用“MCP 构建器”，梳理自动化风险用“自动化治理架构师”，制作 Office/PDF 交付件用“文档生成器”。

供应链部（5）与支持部（7）

供应链部：库存预测专家、物流路线优化师、供应链采购策略师、供应商评估专家、服装工厂规划工程师。

支持部：数据分析师、高管摘要师、财务追踪员、基础设施运维师、法务合规员、招聘运营专家、客服响应者。

供应链角色分别覆盖预测、运输、采购、供应商和工厂产能规划；支持角色适合把业务资料压缩为决策信息，或承接运维、合规、招聘和客服的日常标准化工作。

测试部（9）与 GIS 部（13）

测试部：无障碍审核员、API 测试员、嵌入式测试工程师、证据收集者、性能基准师、现实检验者、测试结果分析师、工具评估师、工作流优化师。

GIS 部：三维场景开发者、GIS 分析师、BIM/GIS 专家、地图制图设计师、无人机实景测绘专家、GeoAI/ML 工程师、地理处理专家、GIS 质检工程师、解决方案工程师、空间数据工程师、空间数据科学家、技术顾问、Web GIS 开发工程师。

测试角色按测试类型选择，并将“证据收集者”或“现实检验者”放在发布前；GIS 角色按数据、分析、制图、三维、Web、无人机和 BIM 的实际产物选择。

安全部（10）

应用安全工程师、安全架构师、区块链安全审计师、云安全架构师、合规审计师、事件响应专家、渗透测试员、高级安全运营工程师、威胁检测工程师（安全运营）、威胁情报分析师。

架构设计找安全架构师，开发流程和代码找应用安全工程师，云/IaC 找云安全架构师，授权测试找渗透测试员，事件中找事件响应专家，合规认证找合规审计师，检测规则和情报分别找威胁检测与威胁情报角色。

七、我的默认组合清单

目标	主责角色	建议复核角色
新增 Web 功能	前端开发者 / 后端架构师	API 测试员、应用安全工程师
代码库排查	代码库入职引导工程师	代码审查员、最小变更工程师
数据库慢查询	数据库优化师	性能基准师
线上事故	故障响应指挥官	SRE、事件响应专家
CSDN 技术文章	技术文档工程师	技术翻译专家、内容创作者
小红书内容	小红书运营专家	图像提示词工程师、品牌守护者
产品排期	产品经理 / Sprint 排序师	高级项目经理
合同或数据制度	合同审查专家 / 制度文件撰写专家	法务合规员

八、结语：先把角色当作“专业检查表”

268 个角色并不要求全部启用。真正有效的方式是：在每个任务里选择一个最贴近交付物的主责角色，用清晰的输入和验收标准约束它；当风险、复杂度或跨专业协作增加时，再增加独立的审查或验证角色。

这样使用，角色库不会变成堆在目录里的提示词，而会成为我在开发、运营、内容和决策工作中可重复调用的专业工作流。

写作日志

• 基于本地已安装的 268 个 Codex TOML 角色、项目 README 与 CATALOG 整理。
• 已保留项目级安装边界、明确角色点名调用方式，并对金融、法律、医疗、安全和真实发布标注人工复核要求。
• 已逐项比对角色名称；对工程侧与安全运营侧的威胁检测角色、两类招聘角色保留精确名称，避免同名误用。