智能体角色

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

这些限制正是设计初衷。无法编写代码的智能体绝不会意外 生成代码。

智能体角色#

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

前四类是每项任务中都会出现的交付智能体。在标准模式下，它们的 运行顺序如下：

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

在协调员模式下，协调员会在任务执行过程中决定后续流程。这两种模式 下文均有详细说明。

只有开发人员这一种角色能够修改您代码库中的文件。其他所有智能体仅负责读取、运行、汇报或创建后续任务。

任务的两种运行方式#

任务有两种运行模式。其AI 配置文件和您的部署配置决定了具体采用哪种模式。

协调员模式。架构师不会制定计划后就离开。它会作为协调员全程跟进任务。规划完成后，协调员会向开发人员下达指令并等待汇报结果。随后它会要求质量保证人员进行验证，再让审核员审核质量保证人员通过的内容。每次收到汇报后，协调员会决定后续流程：将发现结果反馈给开发人员、解答疑问、修订计划，或是结束任务。返工只是协调员的额外步骤，并非全新运行流程。

标准模式。平台会按固定顺序将任务交由四类智能体处理，若检查未通过则会将其退回给开发人员。部分工作始终采用此模式，例如解决合并冲突；当协调员模式不可用时，标准模式即为默认选项。

两种模式下负责工作的智能体相同，限制和关卡也一致。区别在于下一步决策者不同：标准模式下由平台决定，协调员模式下由协调员决定。

协调员#

协调员是负责规划的智能体，会全程跟进任务。它可读取您的代码库但无法修改，因此所有操作仅为引导而已。

协调员的工作内容#

• 制定计划。协调员会先调研代码库，随后保存包含验收标准的计划，用以判定工作是否达标。
• 委派任务。协调员一次只与一名智能体协作。其指令会明确说明目标、需重点关注的验收标准，以及回传任务时的具体修复要求。智能体执行期间，协调员会等待且不占用模型算力。
• 解答疑问。智能体遇到决策难题时可向协调员询问。协调员会给出决策结果及原因，不会让问题搁置等待人工处理。
• 做出响应。若质量保障环节未通过，或审核人员提出修改要求， 协调员会将修复方案发送给开发人员，随后由质量保障人员验证新版本。
• 结束任务。协调员会完成任务，或判定任务失败并说明原因。

协调员无法执行的操作#

协调员负责引导流程，而非做出评判。平台会强制执行这些限制，因此 它们并不取决于协调员的决策：

1. 评判权归属于质量保障人员和审核人员。只有质量保障人员和审核人员才能给出评判， 且各自的结果相互独立。协调员的指令中不包含评判内容，协调员也无法标记检查结果为通过。
2. 完成任务需经过相关关卡。只有当QA验证了即将发布的准确版本（或代码无变动时的当前版本），且若任务需要审核，经审核人批准后，任务才能结束。若QA运行后分支发生变动，则无法结束任务，新版本需重新提交给QA。
3. 返工次数受限。每个智能体在单个任务中可启动的次数有限，计划的修订次数也有限。步骤数量和总运行时间同样设有上限。达到上限后，协调员只能结束或判定任务失败。
4. 等待时间受限。每次等待都有截止时间。

由协调员引导的任务最终会有三种结果：生成供您审批的pull request；QA确认代码已满足任务要求，无需再做改动；或任务失败并说明原因。任务不会因负责Agent自行声明完成而结束。

协调员的可选路径#

协调员决定任务如何通过各关卡。所有路径上的上述关卡标准一致。

• 完整路径。规划、构建、验证、审核、结束。除非协调员有理由选择其他路径，否则任务均按此流程运行。
• 退回工作。若QA未通过或审核人要求修改，修复内容会退回给开发者。新版本必须通过QA验证后，任务才能结束。早期版本的通过结果不能延用至新版本。
• 已完成。代码可能已满足任务要求。此时协调员可让QA直接对照验收标准验证未变动的代码，无需重新构建。若QA通过且审核人批准（如需审核），任务无需生成pull request即可结束，因为无需合并任何内容。QA的验证结果即为任务结论。一旦运行过程产生变动，该路径即被关闭，否则QA可能会通过并非最终发布版本的代码。

有两条可选捷径。Coroid默认不启用它们。它们仅改变协调员的路径，不影响关卡设置：

• 快速修改。针对已知位置的微小修复，协调员会制定更简明的计划，并向开发者给出明确的指令，指明需修改的文件。开发者需在更有限的步骤预算内完成工作，若修改涉及指定文件之外的内容，需向QA和审核人报告。
• 缩小范围的重新校验。针对QA或审核人发现的问题进行微小修复后，QA会基于该发现及项目测试用例开展验证。QA仍会对整个新版本出具结论。

需要审核人的情况#

默认情况下，单独运行的任务均需经过审核人环节。无论协调员选择何种路径，即便无需改动代码，任务也必须在审核人批准QA通过的版本后才能结束。无论是否需审核，QA始终会执行验证，且审核不能替代QA的通过结果。属于计划一部分的任务遵循对应流程的规则。

Coroid还设有可选的风险导向策略，默认不启用。根据该策略，单独运行的微小常规改动任务无需审核人即可结束。以下情况仍需审核人参与：

• 任务已启动审核流程，或项目的审核规则、组织的质量图谱要求必须安排审核人；
• 改动涉及身份认证、会话、权限、密钥或加密技术、数据库迁移、构建与部署配置、依赖文件，或与外部服务交互的代码；
• 改动规模较大（默认超过80行改动），或包含二进制文件、符号链接或子模块；
• Coroid无法读取该策略或改动本身。存在疑问时，必须安排审核人。

无任何改动的变更无需审核人。这一判定由代码决定，而非协调员，协调员也无法绕过该规则。pull request描述末尾的一行会说明最终判定结果及原因，开头会标注“需要审核人”或“无需审核人”。

架构师#

将您的需求描述转化为规格说明，再将规格说明转化为计划。它会读取代码库以确保计划与实际代码情况相符，但不会编写代码。

其输出结果是构建开始前您需要审批的内容。在协调员模式下，该智能体会继续承担协调员的职责。

开发人员#

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

当审核人员将发现结果反馈回来时，开发人员正是负责处理这些结果的角色。在协调员模式下，协调员会将发现结果及对应的修复方案传递过去。

质量保障#

质量保障人员独立于编写代码的智能体开展验证工作——包括您的测试套件、项目配置的质量关卡以及规格说明中的验收标准。

质量保障人员会给出评判结果。它不会修复自身发现的问题；不合格项会返回给开发人员作为返工处理。

审核人员#

审核人员会查看已完成的差异内容并生成发现结果，同时应用贵组织配置的审核规则。发现结果要么作为返工项返回给开发人员，要么附在pull request上供您查看。

网页测试员#

它会驱动真实浏览器对应用的预览版本进行端到端用户流程测试。在仅靠代码无法验证行为逻辑的场景下，会使用到该智能体。

探索员#

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

依赖分析器#

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

为何这种拆分至关重要#

采用这种工作方式拆分后，会产生以下四个特性：

1. 验证过程独立。负责检查工作的智能体与编写代码的智能体并非同一角色，因此它不会受结果影响。
2. 影响范围受限。只有开发人员角色才拥有写代码工具，因此审核或分析环节的故障不会损坏您的代码库。
3. 每个角色对应适配自身的模型。规划工作需要广博的知识储备；而编写可编译的代码则需要另一类能力。 AI 配置文件正是出于上述原因，它会为每个角色配备对应的模型。
4. 任务是否完成由校验环节判定，而非负责该任务的代理。在协调员模式下，主导任务的代理未经质量保障人员与审核人员的确认，无法终止任务。

下一步#

返回至任务如何转化为 pull request查看这些角色对应的各环节详情，或者Coroid 是什么查看更简洁的概述。