大多数 AI 编码工具都是辅助工具：它们围绕模型构建，外加用于读写文件和执行命令的工具。Claude Code、Codex、OpenCode 和 Pi 都属于这类辅助工具，专为坐在终端前的开发者设计。
Coroid 不使用任何此类工具，它运行自己的工具。
为何不封装现有的工具呢？
上述工具均基于有人值守的场景设计。有人会观察进程、回答疑问、中断执行，或察觉到异常情况。这种假设合理且影响了方方面面——包括错误的呈现方式、上下文的携带量，以及模型返回异常结果时的处理方式。
Coroid 的假设恰恰相反：无人值守。工作在云端运行，由定时任务、监控机制或事件触发，必须在不依赖人工干预的情况下产出可审核的结果或明确的失败信息。
这是两类不同的问题。正因如此才产生了下述诸多特性，而这些特性在终端场景中并无意义。
运行时有何不同？
它假定自己独自运行。当模型返回格式错误的响应或错误的工具调用时，运行循环会自行修复并重试，而非弹出无人应答的提示。无人值守的运行过程若因提问而中断，便是资源的浪费。
它天生就是多智能体架构。该运行循环基于角色构建，这些角色拥有不同权限，按固定顺序或经协调员决策传递任务，而非由单一智能体包办一切。验证工作由未编写代码的智能体执行，协调员无法推翻这一结果，这是架构本身决定的，而非人为要求。协调员还能发现代码已满足任务需求，从而让 QA 无需修改即可验证。所有路径最终都会经过同一套审核关卡。
它设有明确的预算和深度限制。每次执行都受令牌预算和步骤上限约束。缺乏这些限制的话，理解有误的智能体就会持续运行下去。
它将治理机制内嵌其中。策略、质量关卡和审批节点都是执行流程的一部分，而非外部封装，因此阻塞性关卡能在运行过程中中止任务，而非事后才生效。
缓存是首要考虑因素
上下文是智能体运行成本的主要来源，而在云端环境中，同一项目上下文会被多次读取。
出于此原因，运行时大量依赖提示词缓存。您可以在任务的执行轨迹中看到其运作情况，各步骤会报告缓存效率：
9.1k used (90% cached)高缓存命中率是降低运行成本的关键。这也是结构清晰、上下文明确的项目之所以成本更低的原因——稳定的上下文易于缓存，而每次运行都变化的上下文则难以缓存。
这与渐进式技能相辅相成，后者能从源头上控制加载的上下文规模。
实际应用中的表现如何？
- 无需本地设置。无需 CLI、编辑器插件或托管运行环境。Coroid 基于 API，在云端运行。
- 无需订阅第三方工具。您无需为 Coroid 上的编码助手购买授权。模型使用量按 积分或通过 您自己的供应商密钥。
- 工作可无人值守运行。 日程安排以及 钩子得以实现，因为这一切并不依赖开发者机器的运行状态。
- 行为具有一致性。所有人的工作都在同一运行时、遵循相同策略执行，而不受各开发者安装配置的影响。具体安装内容可在 语言支持和智能体环境。
它不会改变什么
辅助工具决定了工作方式，但并不改变边界：所有变更仍以 pull request 形式出现在分支上，不会自动合并，您的分支保护及审核规则与人类贡献者完全一致。