Devin (Cognition)：闭源云端编码 agent，官方博客/文档二手证据（无公开源码）

Devin (Cognition)

一句话定位

Devin（Cognition AI 出品）是完全闭源的云端编码 agent 产品——不存在任何公开源码、 GitHub 仓库、npm 包或可反编译的 CLI 二进制；本 dossier 的全部证据来自 Cognition 官方 工程博客（cognition.com/blog、devin.ai/blog）与官方文档站（docs.devin.ai，Mintlify 托管）以及文档站公开的 OpenAPI schema。这是与本系列其他 harness dossier 相同的方法论 局限（与 Cursor 类似：闭源商用产品，证据止于”文档/博客披露”级别，达不到”源码读出” 级别），但 Devin 的独特之处是官方博客对**微VM沙箱、hypervisor 快照、多 agent 编排 （Agentic MapReduce）**这几块给出了远超同类闭源产品的工程细节披露。

核心架构总览（目录结构关键路径 + 引用的 commit）

不适用传统意义上的”目录结构”：没有可克隆的源码树。证据锚点改为”文档页 + 抓取日期”：

• 产品/文档站：devin.ai（marketing 已并入 cognition.com；cognition.ai 仍可解析但 重定向）、docs.devin.ai（Mintlify 托管，通过 <url>.md raw-markdown 后缀技巧抓取）
• 官方博客：cognition.com/blog、devin.ai/blog
• API 版本：Devin API v3，docs.devin.ai/api-reference/v3/overview，OpenAPI 3.1.0， title: Devin API v3, version: 3.0.0 —— 这是唯一可引用的”版本号”级别锚点
• Windsurf/Codeium 已完全并入 Devin 品牌：devin.ai 导航栏直接链接 Windsurf 内容 （/blog/devin-in-windsurf，04.15.26），Multi-Agents 博客文末原文写道 “We welcome you to try our work at devin.ai or windsurf.com.”
• 抓取日期：2026-07-07，文档页无可见 last-modified 时间戳（持续更新中的文档站）
• 一处未能验证：cognition.ai/blog/dont-build-multi-agents（Walden Yan 前作，Multi-Agents 新博客大量自引用）反复 net::ERR_CONNECTION_CLOSED（代理和直连均失败），未独立验证原文， 仅能通过新博客的自我引述二手了解其结论

Agent Loop（主循环 / 何时继续何时停）

官方未披露内部循环/状态机代码。可观察到的结构性证据（均来自文档，非源码）：

• Session 从 **snapshot（冻结 VM 镜像）**启动，运行至完成或被显式停止/发消息/归档/终止 （docs/api-authentication.md；llms.txt 索引列出 POST .../sessions/{id}/messages、 DELETE .../sessions/{id}＝终止、“Archive session and put it to sleep if currently running”）
• Session 支持休眠与恢复（“The session will be automatically resumed if suspended”）—— 这是 hypervisor 级 pause/resume（见”沙箱”章节）在产品层的对应体现
• docs/session-insights.md：Devin 自身的事后分析按 ACU 用量 + 用户消息数将 session 分类为 XS–XL，L/XL 会被标记为”unhealthy”（“Devin likely encountered significant issues or the task scope was too broad for a single session”）——隐含内部存在一个计算/轮次预算， 且期望任务范围能映射到单个有边界的 session 内
• Devin Review 的 CLI（docs/devin-review.md）展示了一个独立的、更小的只读循环：文件读取 / grep / glob / 固定只读 bash 命令白名单（ls, cat, pwd, file, head, tail, wc, find, tree, stat, du）——这是为 PR 分析设计的受限子 agent 循环，与主编码 session 循环分离
• 关于”Devin 如何判断任务已完成”没有架构级披露，只有 docs/instructing-devin-effectively.md 中的通用提示工程建议（给出明确成功标准时”Devin knows exactly what to achieve”）——这是 prompting 指导，不是架构说明

结论：主循环控制逻辑本身未公开披露；只有外部可观察行为（snapshot 启动、 sleep/resume、基于 ACU 的 session 分级）有文档记录。

记忆与上下文管理（压缩、长期记忆、会话持久化）

• Session 级持久化：完整 VM/session 状态在 hypervisor 层被快照——“We solved this by snapshotting full machine state at the hypervisor level — memory, process trees, and filesystem. Compute shuts down while the agent is idle, and the session resumes exactly where it left off when a CI result or review comment arrives.” （blog-what-we-learned-building-cloud-agents.md）。这是让 agent 能跨越 PR review / CI 等待等异步 SDLC 间隙存活的核心机制——官方明确表示这是在千级并发 session 规模下，比他们 构建过的任何其他基础设施都花更长时间才做到可靠的一块。
• 组织级长期记忆＝“Knowledge”（docs/knowledge.md）：持久化、检索触发的组织内共享笔记。 每条包含 Trigger Description（Devin 用于匹配当前任务上下文以判断相关性的自然语言短语）
  • Content。Devin “automatically recalls relevant Knowledge as necessary”——即 RAG 式 检索，而非始终在上下文中。Knowledge 可绑定到无仓库 / 特定仓库 / 全部仓库。Devin 还会主动 建议新的 Knowledge（基于聊天反馈的自我撰写记忆，需人工批准）。企业版增加三级作用域： Organization Knowledge / Suggestions / Enterprise Knowledge，带”Promote to Enterprise”操作。
• Context Rot 意识 / clean-context 模式：blog-multi-agents-whats-actually-working.md 明确引用 “Context Rot”（引用 Chroma 的公开研究）作为理由，说明一个干净、独立上下文的 reviewer agent 优于与 coder 共享全部累积上下文的 reviewer——“models making less intelligent decisions at longer and longer context lengths… The dedicated review agent gets to skip this extraneous context, only look at the diff, and re-discover any context it needs as it reads the code from scratch.” 这是一个刻意的、以多 agent 架构作为上下文管理 手段的设计，而非单 agent 压缩算法。
• 环境/blueprint 的 “knowledge” 字段（docs/environment-blueprints.md）是一个独立的、 更小的机制：session 启动时加载到上下文的简短命令参考（lint/test/build 命令），按仓库配置， 不会自动执行——文档明确用 callout box 区分它与 Knowledge 产品功能（“Knowledge here vs the Knowledge product feature”）。Devin 还有 Session Insights → Knowledge Usage 标签，回溯 评估每条 knowledge 是否帮助或误导了该 session——这是记忆质量的反馈闭环（见”自进化”章节）。
• 未发现任何关于上下文内压缩/摘要算法的披露（例如类似 Claude Code 的 context compaction）—— 在本次读取的全部来源中都没有找到。

工具体系（定义/调用协议/注册/权限）

• Session 原生工具：Shell、IDE（VSCode）、Browser/“Desktop”（docs/devin-session-tools.md）。 完全交互式——用户可以接管/暂停并运行自己的命令；cookie 持久化贯穿 session 内的浏览器工具交互。
• MCP 是主要的外部工具注册机制，两个独立的 MCP 表面：
  • DeepWiki MCP（mcp.deepwiki.com）——无需鉴权，仅公开仓库，文档/搜索工具。
  • Devin MCP（mcp.devin.ai/mcp，Streamable HTTP；legacy SSE 已弃用）——通过 cog_ 前缀的 service-user key 或 PAT 鉴权；暴露的工具组：仓库文档（read_wiki_structure、 read_wiki_contents、ask_question、list_available_repos）、session 管理 （devin_session_create/search/interact/events/gather）、playbook 管理 （devin_playbook_manage）、knowledge 管理（devin_knowledge_manage）、schedule 管理 （devin_schedule_manage）、集成列表（list_integrations）。企业版 service-user/PAT key 需要 X-Org-Id header（因为是账号级而非组织级作用域，docs/devin-mcp.md）。
  • MCP Marketplace（blog-how-cognition-uses-devin-to-build-devin.md）：一键安装 Vercel、 Atlassian、Notion、Sentry、Neon、Asana、Jam、Datadog、Redshift/Postgres/Snowflake/ BigQuery、Stripe、Plaid、Modal 等，在交互式 session 和 Automations 中均可使用。
• 权限/注册模型：通过 Service Users（角色分配）实现 RBAC；token 格式 cog_<...>； 权限示例直接出现在 OpenAPI schema 中：ManageRepoBlueprints、ViewEnterpriseInfraDetails、 ManageEnterpriseSettings、ImpersonateOrgSessions、UseDevinExpert（门控”Advanced Capabilities”——managed-Devin 编排、session 分析、playbook/knowledge 管理——默认包含在 org_member/org_admin 角色中）。Legacy apk_/apk_user_ key 已弃用，MCP server 明确 不支持这两种旧格式。
• Skills 作为工具作用域限定机制：SKILL.md 中的 allowed-tools frontmatter 字段限制 skill 激活期间 Devin 可用的工具（例如”investigate”类 skill 限制为只读的 Read, Grep, ListDir）——见”Skill 体系”章节。
• Devin Review CLI 暴露一个硬编码的只读工具白名单（见上文”Agent Loop”章节）作为本地、 未鉴权 PR 分析的安全边界。

Prompt 设计（系统提示结构、动态组装）

未发现任何泄露/披露的系统提示原文（闭源，本次调研也未定位到 jailbreak 记录）。披露的是 动态上下文注入的组装机制：

• AGENTS.md（docs/agents-md.md）：开放标准（agents.md），放置于仓库根目录或任意位置； Devin “will look for the file before it starts coding”——setup 命令、代码风格、测试规范、 项目结构、工作流约定作为静态上下文注入。
• Skills（docs/skills.md）：SKILL.md frontmatter（name、description、 allowed-tools、argument-hint、triggers）+ 正文。调用时”Devin reads the full SKILL.md file and injects its body into its current context as a system-level instruction”——即 skill 正文以系统级（非用户级）指令形式，在 session 中途动态注入。 同一时刻只能有一个 skill 激活（替换而非叠加）。支持 $ARGUMENTS/$0/$1 替换以及通过 !`command` 代码块的实时 shell 插值（例如在调用时把 git branch --show-current 的输出注入 prompt）——这是带有实时环境数据的真正动态 prompt 组装。
• Playbooks（docs/creating-playbooks.md）：“like a custom system prompt for a repeated task”，用 Procedure / Advice / Specifications / Forbidden Actions / Required-from-User 几个部分撰写；显式按 session 挂载（不像 Skills 那样自动发现）；可通过 !name 宏调用。
• Knowledge 条目基于 trigger-description 匹配被检索并推测插入相关位置（见”记忆”章节）—— 注入 Knowledge 的具体 prompt 位置/格式未披露。
• **REVIEW.md / AGENTS.md / CLAUDE.md / .cursorrules / .cursor/rules / .windsurfrules / .rules / .mdc / .coderabbit.yaml / greptile.json 均被 Devin Review 显式摄入作为 review 上下文（docs/devin-review.md）——值得注意的跨工具互操作性：Devin 读取竞品的配置 文件（CoderabbitAI 的 .coderabbit.yaml、Greptile 的 greptile.json、Cursor 的 rule 文件）。
• Blueprint 的 knowledge: 段（环境配置）在 session 启动时按仓库加载为 lint/test/build 命令参考（见”记忆”/“工具”章节）。
• 未披露 prompt 缓存策略、消息角色结构，或当 {AGENTS.md, Skill, Playbook, Knowledge, blueprint knowledge} 同时存在时的精确顺序/优先级。

Router / 编排（任务分解、多 agent、子 agent）

这是披露最详尽的维度。三种不同的架构被公开：

1. “Managed Devins” / 协调者模式（docs/advanced-capabilities.md、 blog-multi-agents-whats-actually-working.md）：一个协调者 session 分解大任务，为每个 子任务在独立 VM 中启动子 session，各自拥有自己的 prompt/playbook/tag/ACU 限制； 协调者可以给子 session 发消息、监控 ACU 消耗、休眠/终止子 session、安排自我提醒去检查 长时间运行的子 session。Cognition 明确将其定性为”map-reduce-and-manage”，拒绝 “unstructured swarms”（agent 间任意协商）为”mostly a distraction”。所有 managed-Devin 能力既可在 session 内以自然语言调用，也通过 Devin MCP 工具集调用 （devin_session_create 等，devin_session_gather 用于多个并行子 session 的 barrier 式等待）。
2. Agentic MapReduce（blog-agentic-mapreduce.md）——针对全代码库任务（安全扫描、 破坏性变更检测、大规模迁移、代码质量强制执行）的正式化 4-5 阶段流水线：
   • Plan（agentic）：一个 Devin session 研究仓库并撰写 selectors——具体的、 确定性的相关性测试（Tree-sitter 查询、编译器/符号查询、import/call-graph 遍历、 生成的 API schema diff、词法模式）——持久化/版本控制，可跨运行复用。
   • Shard（非 agentic / 确定性）：selector 在整个仓库上运行，循环中不涉及模型； 每次匹配产生一个 signal（位置＋selector＋证据）；未匹配任何 selector 的文件在 进入昂贵阶段前被丢弃；匹配结果被分桶为有边界的批次（批大小参数，默认 5，范围 1–500，见 docs/security-swarm.md）。
   • Map（agentic）：每个批次一个全新的子 Devin session，并行运行，只给该批次的 signals + provenance——不与兄弟 session 共享上下文。
   • Reduce（agentic）：reducer session 只消费各 worker 的结构化结论（而非完整 transcript），去重、协调，并能组合跨 shard 的发现（例如把一个 shard 中的 未鉴权 ID 泄露和另一个 shard 中的 ID 门控 RCE 串成一个严重级别发现）。
   • Verify（agentic，安全场景特有的第 5 阶段）：orchestrator 为每个严重发现分派一个 沙箱化 session 去在运行中的构建上复现，标记 Confirmed/False-Positive/Inconclusive。
   • 增量重跑：“the entire pipeline runs only on files that changed since the last commit scanned”——成本随 diff 增长，不随仓库大小增长。
   • Security Swarm 是这一模式的旗舰产品（docs/security-swarm.md）：用户可配置的 “scan profile”（威胁模型/调查指引/分诊指引/运行时验证指引/修复指引/包含-排除 glob/批大小），带”Interactive mode”，可在 Plan 后暂停供人工审阅生成的威胁模型再 fan-out。基准测试显示 CVE 召回率 72%（对比 Claude Security 68%、Codex Security 48%、Cursor Security 26%），来源为 GitHub Advisory DB 中钉住修复前 commit 的 真实公开 CVE（成本：$90.23 对比 $131.87/n.a./$4.60——数字仅为 Cognition 自报， 本次调研未独立复核）。
3. 生成器-验证器循环 / “clean-context reviewer” （blog-multi-agents-whats-actually-working.md）：Devin（coder）与 Devin Review （reviewer）原生互相迭代；reviewer 刻意不共享 coder 的上下文（见”记忆”章节——这是 一个文档记录在案的、反直觉的设计选择，不是疏漏）。Devin 平均每个自撰 PR 发现约 2 个 bug，约 58% 被评为严重。Devin/Devin-Review 的 autofix 循环在无人工介入的情况下持续 迭代直到 CI+lint 通过（引用自”Closing the Agent Loop — Devin Autofixes Review Comments”博客，未单独抓取原文）。
4. “Smart Friend” 跨模型委派（同一博客）：较小/便宜的主模型在判断情况”tricky”时可以 中途调用更大/更贵的模型。文档明确披露：当主模型明显弱于 smart friend 时，这一机制尚不 可靠——Cognition 直言这一差距”is a training problem”，归因于模型训练而非 harness 工程，并表示未来的自研 SWE 模型将专门针对这种来回模式进行训练。目前只有当两个模型都是 前沿级时才表现良好（曾在生产环境中让 Claude+GPT 搭配运行”for a meaningful stretch”）。
5. Devin 的 DeepWiki 子 agent（代码库上下文）被 Cognition 自己定性为”resembl[ing] tool calls rather than true multi-agent collaboration”——即 Cognition 自己划出了 只读上下文获取子 agent 与真正多 agent 协作之间的界限。

Skill / 插件体系

完整规范披露于 docs/skills.md。遵循开放的 “Agent Skills” 标准 （agentskills.io/specification）——Devin 明确宣称互操作性（“the same skill files work across multiple AI coding tools”）。

• 文件位置：.agents/skills/<name>/SKILL.md（推荐），另外还扫描 7 个遗留路径以兼容： .devin/skills/、.github/skills/、.claude/skills/、.cursor/skills/、 .codex/skills/、.cognition/skills/、.windsurf/skills/——每个仓库共扫描 8 个路径。
• 每个 session 合并两个发现源：(a) 跨所有已连接仓库的后端索引 SKILL.md（clone 之前即可用）， (b) 已 clone 仓库的实时磁盘扫描（覆盖索引版本，随 clone 完成会在 session 中途自动重新扫描）。
• Frontmatter 字段：name、description、allowed-tools（规范标准字段）+ Devin 专有扩展 argument-hint、triggers（默认 ["user","model"]；设为 ["user"] 可禁用自动调用）。
• 调用方式：自动（模型判断相关性）或显式 @skills:name [args]；同一时刻只有一个 skill 激活（替换而非组合——文档明确列为当前限制，连同缺少组织级/跨仓库 skill）。
• 自撰 skill 创建：测试完一个应用或学到新的配置信息后，Devin 会主动提出”Create PR” 建议并附带草拟的 SKILL.md——一个真正的自我改进/自我文档化闭环（与”自进化”章节相连）。
• 与 Playbooks 的区分：skills 是仓库级、git 版本控制、自动发现的；playbooks 是组织级、 UI 管理、按 session 手动挂载，更适合跨仓库的 prompt 模板（docs/skills.md 的对比表； docs/creating-playbooks.md）。

自进化能力（自我改进 / 学习型记忆 / eval 驱动纠错）

• Session Insights（docs/session-insights.md）是核心的 eval/反馈机制：每个 session 结束时自动做轻量分类（category/languages/tools）；L/XL session 自动生成完整分析，较小 session 按需生成。产出包括：
  • Issue Timeline（分类/影响评级的问题＋彩色标注的时间序事件追踪）
  • Actionable Feedback：一份”Improved Prompt”（与原始 prompt 做 diff，鼠标悬停解释 改动）和”Action Items”（机器设置/仓库配置修复建议）
  • Knowledge Usage：明确标注每条 Knowledge 帮助了还是误导了该 session—— 对长期记忆存储自身质量的直接、逐 session 评估，反馈进 Knowledge 维护流程。
  • Session 大小（XS–XL）阈值基于 ACU 和消息数，企业组织享有 10 倍放大的阈值——意味着 大小/健康分级本身是一个经过调优、持续演进的启发式规则。
• Advanced Capabilities（docs/advanced-capabilities.md）明确将”self-improvement” 暴露为一项按需能力，而非被动分析：Devin 可被要求 (a) 分析过去的 session 并解释成功/ 失败原因，(b) 基于一次成功的 session 创建新 playbook或用失败的 session 作为反例 来优化已有 playbook，(c) 对代码库模式去重/合并/创建 Knowledge 条目，(d) 设置定期 自维护任务（例如每周的 Knowledge 卫生检查）。这是一个记录在案的闭环： session → insight → playbook/knowledge 变更 → 更好的未来 session。
  • Skills 自动建议（“Skill 体系”章节）是同一模式在仓库作用域的体现： session → 学到的流程 → SKILL.md PR 建议。
  • Security Swarm 的”Feedback”操作（docs/security-swarm.md）：用户对特定发现的 反馈”refines the scan profile for future scans”——安全扫描产品特有的 eval 纠错闭环。
• 未发现任何将 session 轨迹用于重新训练或微调Devin 底层模型的机制披露（见”轨迹利用” 章节）——这里披露的自进化完全发生在制品层（playbooks、knowledge、skills、scan profiles），不是权重更新。
• Cognition 自己的 dogfooding 博客（blog-how-cognition-uses-devin-to-build-devin.md） 本身就是 eval 驱动改进文化的证据：“we merged 659 Devin PRs into our own codebase [in one week], up from 154 in our best week in 2025”——作为内部速度指标使用，另外还描述了 每日自动化设计系统违规审计，以及与 Datadog 集成的自动化 bug 分诊/端到端调试流水线， 在工程师看到 bug 之前就把人工排查步骤压缩为零。

可观测性（日志 / trace 格式）

• 审计日志：GET /v3/enterprise/audit-logs 及组织级对应端点（据 llms.txt 索引）； guardrail 违规专门以 ai_guardrail_violation action type 出现在审计日志中 （docs/ai-guardrails.md）——暗示存在更广泛的类型化审计事件 schema（本次调研只直接确认了 这一个 action type 的名称）。
• Session 事件 API：devin_session_events MCP 工具及 REST 对应端点（“list session messages”、“get session insights”）暴露一个结构化、可查询的逐 session 事件时间线—— “list event summaries, fetch full event details, or search event contents by text” （docs/devin-mcp.md）。这是最接近公开”trace 格式”的东西——session 被分解为类型化 事件（shell 命令、代码编辑、浏览器操作、进度更新），既通过 Progress 标签 UI 展示， 也通过同一份数据的 API 暴露（docs/devin-session-tools.md、docs/devin-mcp.md）。
• Metrics API 表面（来自 llms.txt）：DAU/WAU/MAU、PR 指标、搜索指标、session 指标、 按类别的 session 指标、用量指标——企业级和按组织/用户/session 的每日消耗（ACU 计价） 分解均有。这是一个真实、相当丰富的企业可观测性 API，但本次笔记只确认了字段/端点的 存在（来自文档索引），未逐个抓取 metrics 端点的完整 response schema。
• Guardrail 违规记录 schema（经 OpenAPI 确认，docs/api-v3-guardrail-violations.md）： violation_id, org_id, session_id, event_id, guardrail_id, guardrail_name, confidence_score, action_taken, reasoning, user_message, created_at——即每个 guardrail 决策都带有模型生成的 reasoning 字符串和 confidence_score，不只是布尔值的 阻断/放行。
• Hypervisor 状态 API（经 OpenAPI 确认，docs/api-v3-hypervisors.md）： hypervisor_id, status (available/restarting/disconnected/terminated/draining), utilization_percentage, created_at, last_heartbeat, cloud_provider_instance_id——这是 面向”VPC monitoring”目的的基础设施级可观测性，让企业客户能看到支撑其 session 的 microVM 舰队健康状况。这是对云 agent 博客中微VM/hypervisor 架构说法的直接印证——有真实、已上线 的 API 表面作为证据。
• 未披露实际的 trace/日志线格式（例如是否兼容 OpenTelemetry、JSON lines 还是私有格式）—— 只有概念层面的事件/指标分类是公开的。

安全与权限（审批门、密钥管理）

• 密钥（docs/secrets.md）：四种类型——Raw（单一 K/V）、Site Cookies（base64 编码的 分号分隔 JSON 数组，Chromium 格式 cookie——用于保持已登录的浏览器状态）、TOTP（2FA， 从二维码派生）、Key-Value（已弃用）。三种作用域：组织级（管理员管理，全成员可用但 只有管理员可见）、个人级（仅 session 创建者可见，组织内其他成员不可见）、仓库级 （通过 blueprint 的 maintenance/Secrets 标签作为环境变量——作用域限定在使用该 snapshot 的 session）、session 级（临时的，由 Devin 在 session 中途请求或用户设置，不会 持久化超出该 session）。新增密钥只对该密钥添加之后创建的 session 可用（不追溯注入）。 Devin 自动将密钥名清洗为合法的 ENV_VAR 标识符（非法字符替换、前导数字加前缀、冲突加后缀）—— 这是密钥注入机制的一个具体、已披露的实现细节。
• AI Guardrails（docs/ai-guardrails.md，仅企业版）：一个独立的筛查层，在 Devin 处理每条传入用户消息（初始消息、后续消息、PR 评论）之前运行，专门针对prompt injection、数据泄露尝试、策略违规。每条 guardrail 规则可配置四种动作： log_only、warn_user、block_message、kill_session（终止 session 是最严重的一档）。 每次违规都可审计（session 链接＋匹配规则＋置信度＋推理，见”可观测性”章节）。这是最明确 披露的”审批/安全门”机制——实现为独立的分类器层，门控用户→agent 消息通道，而非 工具调用级的人工审批（本次调研未发现逐工具调用的人工审批 UI 证据，除了”Agent Loop” 章节描述的通用”接管 session”交互式暂停）。
• RBAC / 权限模型（docs/api-authentication.md）：principal+token 模型——Service User（非人类，RBAC 角色分配）vs Personal Access Token（人类，封闭 beta，继承 人类自身的权限/审计轨迹）。所有当前一代 token 使用 cog_ 前缀；legacy apk_/ apk_user_ 已弃用，MCP server 明确拒绝。Service user 可以是组织级 （/v3/organizations/*）或企业级（/v3/enterprise/* + /v3/organizations/*）作用域； create_as_user_id 让 service user 创建的 session 归属（并计入用量）某个特定人类， 由 ImpersonateOrgSessions 权限门控——一个刻意窄化、明确授权的模拟原语，而非一揽子能力。
• 安全态势披露（docs/admin-security.md）：SOC 2 Type II 认证（2024年3月审计）、 全员 MFA + 年度安全培训、传输/静态加密、漏洞披露计划（security@cognition.ai）、 数据保留期限定为客户关系存续期、付费计划可选择关闭”用于模型训练”（关闭后可与模型提供方 实现”Zero Data Retention”）、企业客户获得未经同意不训练的合同保证。GitHub/Slack 集成 权限范围在安装时由管理员控制。
• Devin Review 本地 CLI 信任边界（docs/devin-review.md）：运行一个仅本地的 server 做 review-session 鉴权——只有本地进程能读取 token，因此未登录用户的 review 页面在网络拓扑层面天然私有，直到用户显式登录将 session 转移到自己账户下。这是 CLI 鉴权 设计中”最小暴露原则”的一个具体、已披露的例子。
• 规模化治理/审计：blog-what-we-learned-building-cloud-agents.md 明确列出企业为 云 agent 治理必须自建/采购的三大支柱——从派发工程师继承的权限、每个动作的防篡改审计轨迹、 按外部系统限定的集成权限范围——并表示 Cognition 为这套体系的每一层都配备”a dedicated team”，暗示公开 API 的 RBAC/审计日志表面之下有大量未公开的内部基础设施。

沙箱与执行隔离

这是披露最详尽、证据最扎实的维度——blog-what-we-learned-building-cloud-agents.md 的核心内容：

• 明确拒绝容器化隔离方案：“Containerized agents share a kernel, which means one compromised session can access every other container’s filesystems, credentials, and network connections.” Agent 生成的任意代码/命令使内核级逃逸成为现实威胁模型，而非 理论威胁。
• 采用 microVM 级隔离：“each workload gets its own kernel, with no shared attack surface.” 明确表示花了**“over a year of hypervisor engineering”**来实现，保证每个 session 运行在自己独立的内核上，存储、网络、计算完全隔离。附带优势：独立 VM 让 agent 能运行完整的浏览器/桌面应用/任意工具栈，“just like a developer on their workstation”—— 这直接解释了”工具体系”章节中 Shell/IDE/Browser(“Desktop”) session 工具的由来。
• 全机器状态快照在 hypervisor 层完成（内存＋进程树＋文件系统），是让 session 计算 能在空闲时关停（节省成本，避免”烧计算硬扛异步间隙”的反模式）并在例如 CI 结果或 review 评论到达时精确恢复到离开时的状态的机制——明确称为 Cognition 构建过的最难 一块基础设施，比其他任何东西都难，具体原因是”thousands of concurrent sessions, each with different repos, dependencies, and runtime environments”的扩展性要求。
• 编排层耗费了”over three quarters of dedicated engineering”，管理千级并发 VM 规模下 的资源预配、需求预测（保持热 VM 池待命）、崩溃恢复和资源回收。
• Snapshot/Build/Blueprint 机制（同一基础设施的产品化表面， docs/environment-blueprints.md）：环境＝Linux VM；blueprint YAML（类 Dockerfile） → build（类 docker-build，约 5-15 分钟，每步 1 小时超时，同一时刻只跑一个 build， 新保存会取消排队中的 build）→ snapshot（类 docker-image——每个组织一个活跃 snapshot；每个 session 启动一份全新拷贝；session 内的改动永不回写持久化）。 三层 blueprint 层级（企业级→组织级→仓库级），严格叠加不覆盖；build 顺序确定性 （企业 init/maintenance → 组织 init/maintenance → 最多并发 10 个仓库 clone → 按配置 顺序逐仓库 init/maintenance → 健康检查 → 保存）。部分成功语义：一个损坏的仓库 blueprint 不会使整个 snapshot 失效。约每 24 小时定期重建以保持依赖新鲜；支持 pin 固定一个已知良好的 snapshot。Git 支持的 blueprint（仓库内 .devin/blueprint.yaml + 同步 API）让团队像 review 应用代码一样 review 环境配置。
• 企业版 Hypervisor 状态 API（docs/api-v3-hypervisors.md，经 OpenAPI 确认）是上述 说法的真实、已上线证据：hypervisor_id / status (available|restarting|disconnected| terminated|draining) / utilization_percentage / last_heartbeat / cloud_provider_instance_id——枚举值本身（draining、disconnected、restarting） 暗示存在一套与博客说法一致的、活跃的舰队生命周期管理系统。
• Security Swarm 的运行时验证阶段（docs/security-swarm.md）为每个严重发现运行”one sandboxed session”，在运行中的构建上复现漏洞——即同一个沙箱原语被复用为一次性、可丢弃的 验证环境，文档明确警告只应使用非生产测试数据。

与模型的协同设计

Cognition 既是 harness/产品公司，也是模型实验室——自研 SWE 系列模型 （SWE-1.5、SWE-1.6），专门为配合这些 harness 模式而设计：

• “Smart Friend” 委派（blog-multi-agents-whats-actually-working.md）：SWE-1.5 （950 tok/sec）被明确以 Sonnet 4.5 作为”smart friend”进行基准测试——发现能力差距 具体表现在”knowing when to escalate, knowing what to ask”，Cognition 明确表示 “We’re reasonably confident this is a training problem, and future SWE models will be trained with this back-and-forth in mind.” SWE-1.6（号称在 SWE-bench 上达到 Opus-4.5 水平）缩小但未消除这一差距。这是 harness 模式需求反哺模型后训练优先级的一个 直接、具名的例子。
• 跨前沿模型委派（Claude+GPT 在生产环境中一起作为 coder+smart-friend 运行）据报道需要 与”弱主模型”场景不同的 prompt 调优——“routing to whichever model is best at the specific sub-task… becomes a capability router rather than a difficulty escalator”——暗示 harness 侧的启发式规则是感知模型身份的，而非模型无关的。
• Agentic MapReduce 的 selector 撰写步骤和 Security Swarm 的威胁模型生成都是 “用一次强模型来撰写一个确定性制品（一条 selector 查询、一份 scan profile），从而 无论仓库规模多大，昂贵的推理成本只需支付一次”这种 harness 设计模式的例子—— 这种设计明确围绕一个假设模型提供方具备的特定能力（可靠的结构化制品生成）构建，而不是 依赖无限增大的上下文窗口。
• 提及 “Mythos class”（Multi-Agents 博客引用的 www-cdn.anthropic.com PDF 中的更大/ 更强的即将推出的 Anthropic 模型）作为多 agent 成本削减工作的一个明确动机——Cognition 将其 harness 路线图明确定位为对第三方实验室预期前沿模型成本/能力轨迹的响应，而非 仅仅围绕自己的模型。
• 本次调研未定位到 SWE-1.5/1.6 的微调细节、RL 环境或训练数据配方（超出本任务”harness” 框定的来源范围——需要专门的 SWE-1.5/1.6 博客文章，本次未抓取）。

轨迹利用（session/trajectory 是否反哺训练/评测）

• 训练反馈闭环，仅在数据使用政策层面披露（docs/admin-security.md，“How is your data used to improve Devin?“）：“By default, we may use your data for model training purposes to improve and enhance the Services.” 付费计划客户可选择退出（启用与模型 提供方的”Zero Data Retention”）；Teams 计划的退出仅限管理员操作；企业客户获得未经 同意不训练的合同保证。这直接证实 Devin 的 session 轨迹（对于未退出、非企业版客户） 默认是 Cognition 自身模型训练的候选数据源——但未披露进一步细节（占比、过滤方式、 RLHF vs SFT vs 仅用于 eval）。
• eval 使用，已确认且有细节：Security Swarm 针对”a ground-truth set of real, published vulnerabilities… CVEs from the GitHub Advisory Database, each pinned to the exact commit before its fix landed”（blog-agentic-mapreduce.md）做了基准测试——这是 一个外部的、静态的 eval 集，不是原始客户轨迹，但证实 Cognition 对自家产品和具名竞品 （Claude Security、Codex Security、Cursor Security）运行严格的定量评测（召回率%和单次 运行成本）。
• 制品层轨迹复用（非权重训练）：如”自进化”章节所述，单条 session 轨迹被明确复用于 (a) 生成 Session Insights / 改进版 prompt 建议，(b) 培育新 Playbook 或优化已有 Playbook，(c) 培育新的 SKILL.md 建议，(d) 通过”Feedback”操作优化 Security Swarm 的 scan profile。这四条都是session → 派生制品的流水线，需要人工审阅/批准该制品才会 生效——即用于制品生成的轨迹复用是真实且有详细文档的；用于字面意义上模型权重重训练的 轨迹复用只在政策层面被断言（“may use your data for model training”这句话），没有 进一步的技术披露（流水线、过滤方式、评估方法均未披露）。
• 未找到任何类似部分竞品所披露的内部”trajectory museum”/数据集策划流水线（例如从成功 agent 轨迹构建的策划过的 SFT 集）的公开披露——Cognition 的公开材料止步于上述政策层面 的表述。

与同类 harness 的关键差异（1-3 条，可以先留一句概述，后续 synthesis 阶段会做跨 harness 对比）

1. 沙箱隔离的披露深度远超同类闭源产品：多数闭源 coding agent（如 Cursor）在沙箱/ 隔离层面几乎没有工程细节披露，Devin 的官方博客罕见地公开了”容器化 vs microVM”的 决策过程、耗时（“over a year”）以及真实的企业 Hypervisor 状态 OpenAPI schema 作为 佐证——这是本 dossier 系列中沙箱维度证据最扎实的闭源产品之一。
2. 多 agent 编排的正式化程度高：Agentic MapReduce 把”Plan/Shard/Map/Reduce/Verify” 固化为一个可复用、可增量重跑的产品级流水线（Security Swarm），并给出可与竞品对比的 基准数字（72% vs 68%/48%/26% 召回率）——比大多数 harness 停留在”多 agent 编排存在” 层面的披露更进一步到了”分阶段架构+成本模型+基准评测”。
3. 诚实披露 harness-模型能力缺口是训练问题而非工程问题：Cognition 明确将”Smart Friend”委派机制在弱主模型场景下不可靠的原因归为”a training problem”，并表示未来 自研模型会针对该模式做后训练——这种”harness 需求反哺模型训练优先级”的具名闭环，在 本系列其他 harness dossier 中较少见到如此直接的公司自述。

原始源码定位

• repo：无公开源码（无 GitHub org、无 npm 包、无可反编译二进制；cognition.ai 重定向至 cognition.com，产品/文档在 devin.ai / docs.devin.ai）
• commit/version analyzed：N/A；最接近的版本锚点为 Devin API v3 （docs.devin.ai/api-reference/v3/overview，OpenAPI info.version: 3.0.0），全部 博客/文档内容的抓取日期为 2026-07-07
• 关键文件列表（相对路径，均为本地保存的抓取文件，非源码）：
  • NOTES.md（532 行，本 dossier 的主要依据）
  • blog-what-we-learned-building-cloud-agents.md
  • blog-agentic-mapreduce.md
  • blog-multi-agents-whats-actually-working.md
  • blog-how-cognition-uses-devin-to-build-devin.md
  • docs/admin-security.md
  • docs/devin-session-tools.md
  • docs/devin-mcp.md
  • docs/skills.md
  • docs/knowledge.md
  • docs/security-swarm.md
  • docs/advanced-capabilities.md
  • docs/creating-playbooks.md
  • docs/agents-md.md
  • docs/devin-cli.md
  • docs/session-insights.md
  • docs/secrets.md
  • docs/index-repo.md
  • docs/instructing-devin-effectively.md
  • docs/automations.md
  • docs/environment.md
  • docs/environment-blueprints.md
  • docs/api-v3-hypervisors.md
  • docs/api-v3-guardrail-violations.md
  • docs/devin-review.md
  • docs/ai-guardrails.md
  • docs/api-authentication.md
  • docs/llms-txt-index-partial.txt

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/devin-cognition/ 下保存的文件：

• NOTES.md
• blog-agentic-mapreduce.md
• blog-how-cognition-uses-devin-to-build-devin.md
• blog-multi-agents-whats-actually-working.md
• blog-what-we-learned-building-cloud-agents.md
• docs/admin-security.md
• docs/advanced-capabilities.md
• docs/agents-md.md
• docs/ai-guardrails.md
• docs/api-authentication.md
• docs/api-v3-guardrail-violations.md
• docs/api-v3-hypervisors.md
• docs/automations.md
• docs/creating-playbooks.md
• docs/devin-cli.md
• docs/devin-mcp.md
• docs/devin-review.md
• docs/devin-session-tools.md
• docs/environment-blueprints.md
• docs/environment.md
• docs/index-repo.md
• docs/instructing-devin-effectively.md
• docs/knowledge.md
• docs/llms-txt-index-partial.txt
• docs/secrets.md
• docs/security-swarm.md
• docs/session-insights.md
• docs/skills.md