智能体角色

Coroid 不会采用通用型智能体。任务处理的每个阶段从需求描述到交付 pull request 的流程均由职责明确且工具集受限的智能体负责处理。

设置这些限制正是核心目的。无法编写代码的智能体绝不会意外生成代码。

智能体角色

角色	阶段	可修改代码
架构师	需求说明与规划	否
开发人员	构建	是
质量保证人员	验证	否
审核员	审核	否
网页测试员	验证浏览器操作流程	否
探索员	任意阶段的研究工作	否
依赖分析器	分析	否

前四个角色构成了每个任务中按此顺序执行的流程：

架构师→开发人员→质量保障人员→审核员

仅有一个角色——即开发人员——能够修改代码库中的文件。其他所有代理仅负责读取、运行、汇报或创建后续工作任务。

架构师

它将你的需求描述转化为技术方案，再将技术方案细化为执行计划。它会查阅代码库以确保计划与实际代码情况相符，但不会编写任何代码。

其输出即为构建启动前需你审批的内容。

开发者

负责执行工作：读取相关代码、做出修改、编写或更新测试用例，并在工作区本地运行直至测试通过。

当审核员将发现结果反馈回来时，开发者正是负责处理这些结果的角色。

质量保证人员

独立于编写代码的智能体独立开展验证工作——包括运行你的测试套件、执行项目配置的质量检查规则，以及核对需求文档中的验收标准。

质量保证人员会给出判定结果。他们不会修复所发现的问题；相关故障会反馈给开发者作为返工任务处理。

审核员

审核员会阅读完整的代码差异内容并生成发现结果，同时应用贵组织配置的审核规则。这些发现结果要么作为返工任务反馈给开发者，要么附在pull request上供你查看。

网页测试员

它会针对应用的实时预览版本在真实浏览器中运行测试，以校验端到端的用户流程。当无法仅通过代码判断行为是否符合预期时，便会使用该角色。

探索员

这是一种只读型调研角色。其他智能体会借助它来解答关于代码库的问题，无需将全部内容加载到自身上下文中——比如“身份验证逻辑在哪里处理”、“哪个函数调用了它”。

依赖分析员

它会分析代码间的依赖关系以及变更在代码库中的传播路径，包括配置了跨项目依赖的场景。

为何这种分工至关重要

采用这种分工方式会带来三个特性：

**验证过程具备独立性。**负责检查工作的智能体与编写代码的智能体并非同一角色，因此它对结果并无利害关系。
**影响范围受到限制。**只有开发者角色才拥有代码编写工具，因此审核或分析环节出现的问题不会损坏你的代码库。
**每个角色都会运行适配自身的模型。**规划环节需要广博的世界知识；而编写可编译的代码则需要另一类能力。 AI 配置文件正是出于这一原因，它会为每个角色配备专属模型。

下一步

返回至任务如何转化为pull request查看这些角色对应的阶段划分，或者Coroid是什么查看更简洁的概述。

智能体角色