AI Research 技术调研

阿里 Qoder（原通义灵码）：闭源 CLI，权限/hook/子agent 三套编排文档极详但核心 agent loop 不可读源码

30分钟阅读

阿里 Qoder（原通义灵码 Tongyi Lingma）

一句话定位

Qoder CLI（qodercli）本体是闭源产品，仅以 npm 私有包 @qoder-ai/qodercli 形式分发（无公开源码），任务给出的 https://qoder.com/ 只是营销站而非代码仓库；GitHub 上搜索”qoder”的 680 条结果里，大多数是第三方逆向/试用重置/API 代理工具（如 cubk1/qoder2api、itandelin/qoder-free），这本身就是”没有合法开源客户端可用”的间接证据。本 dossier 的证据基础因此是三类：(1) 官方 GitHub 组织 QoderAI/Qoder-AI 下两个可读的辅助仓库（GitHub Action 包装器 + ACP 参考客户端），展示了闭源二进制的”外部行为”；(2) 官方文档站 docs.qoder.com（Mintlify 托管，异常详细，覆盖记忆/权限/hook/子agent/插件/ACP/云端 Cloud Agents 平台的内部机制描述）；(3) 一个社区皮肤仓库（Qoder-AI/qoder-community）。没有任何一处能读到核心 agent loop / 工具分发 / 系统提示的源码——本页所有架构性论断均标注来自文档还是代码，请勿混淆两者的证据强度。

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

  • 核心产品 qodercli：闭源 npm 包 @qoder-ai/qodercli，无公开源码；版本号仅能从第三方引用处推断，例如 qoder-action/action.yml 里固定 qodercli_version: 0.1.18（official-repos/qoder-action/action.yml）。
  • 官方可读辅助仓库（均已 clone 到本地 sources/harness/alibaba-qoder/official-repos/）：
    • github.com/QoderAI/qoder-action（MIT，commit 0881d27d15a7a93778ebc5c942d11da313ee8b7e）——包装闭源 qodercli 的 GitHub Action：安装脚本、OIDC 认证交换、MCP 安装脚本、stream-json 输出解析器，以及随 Action 分发的内置子agent/命令 Markdown 定义（.qoder/agents/*.md、.qoder/commands/*.md）。
    • github.com/QoderAI/qoder-acp-demos（commit 3915960f9472a6d38560d226bb2ec7ba619d986d）——官方 TypeScript 参考客户端，通过 stdio NDJSON 驱动真实的 qodercli --acp 子进程，是从外部观察闭源二进制”循环行为”的最佳窗口。
    • github.com/Qoder-AI/qoder-community（注意大小写与 QoderAI 不同，commit 9d67b44cdca0cedae2067759d5d5bff9c0004a45）——Astro 静态站源码，含 AGENTS.md 项目上下文文件范例、skill frontmatter 模板、一个社区提交的 coding-agent skill（展示真实 CLI 调用参数）。
    • github.com/QoderAI/skills（commit a028ed30b12deb53861c06f652b86c8a91798eee）——仅一行 README 的空占位仓库，不是技能库，已核实无实质内容。
    • 另有 QoderAI/cloud-agents-cli、QoderAI/cloud-agents-sdk-go、QoderAI/qoder-sdk-demos、QoderAI/qoder-community（QoderAI 大小写这个是空的，真实内容在 Qoder-AI/qoder-community）经 git clone --depth 1 验证为空仓库，不可用。
  • 官方文档站 docs.qoder.com：本次经 .md 后缀端点抓取 26 篇，落盘于 sources/harness/alibaba-qoder/docs/doc-*.md，覆盖 CLI 侧（memory/permissions/hooks/subagent/plugins/mcp-servers/acp/cloud-mode/Skills/SDK 五篇）与独立的 Cloud Agents 云端产品线（overview/memory-stores/dreams/managed-agents/permission-policies/tools/skills）。
  • 结论性说明：不存在可指向具体行号的核心 agent-loop/工具分发/prompt 模板源码；以下各节凡引用 docs/doc-*.md 均为官方文档转录而非代码读取，凡引用 official-repos/ 下文件才是真正的源码级引用。

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

闭源二进制内部循环实现不可见。可核实的间接证据全部来自 hook 契约文档（docs/doc-en_cli_hooks.md）：

  • Stop hook 在”主 Agent 结束响应且无待处理工具调用”时触发；hook 若以 exit code 2 返回，可以注入消息、阻止本次停止，迫使循环继续——即 harness 把”是否继续”这一权力显式暴露给了 hook 层，而非完全内部黑盒决策。为防止死循环，事件里带 stop_hook_active 字段供 hook 作者规避 Stop-hook 无限触发自己。
  • SubagentStop 是同一机制作用于单个子agent 回合的版本。
  • --max-turns（CLI flag）/ maxTurns（子agent frontmatter 及 SDK AgentDefinition 字段）是跨所有接口统一的硬性迭代上限。
  • Goal Mode（/goal set <objective>）是文档中最接近”自治外层循环”的用户可见抽象：设置目标后会锁定权限模式开关，防止意外打断（docs/doc-en_cli_permissions.md）。
  • Cloud Agents 侧（云端产品线，与 CLI 是不同代码路径）：回合结束表现为 session.status_idle + 一个 stop_reason 对象；stop_reason.type: "requires_action" 是一种”循环暂停”状态，客户端回传事件（user.tool_confirmation）后循环在同一回合内恢复（docs/doc-cloud-agents_permission-policies.md）。

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

CLI 侧记忆分两层（docs/doc-en_cli_memory.md）：

  • 静态记忆：AGENTS.md + .qoder/rules/**/*.md，人类/团队编写，从当前目录向上搜索直到 .git 为止；规则支持 4 种激活模式（always_on/manual/model_decision/glob），支持 @path 形式的文件导入。
  • 自动记忆：模型自主写入，需显式 QODER_MEMORY=1 环境变量开启；内容分 4 类（user/feedback/project/reference）；索引文件 MEMORY.md 启动时加载但截断到前 200 行/约 25KB，详情放在独立 topic 文件里，避免索引膨胀吃掉上下文预算。

上下文压缩：/compact 命令 + 接近上下文窗口上限时的自动触发；PreCompact/PostCompact hook 可以观察甚至阻断压缩过程。值得注意的是桌面端（Desktop/QoderWork）没有做成完全静默的自动压缩：文档 docs/doc-user-guide_chat_smart-context-control.md 明确写超过 40% 窗口占用时会向用户展示”Compact Chat”（有损摘要）vs “New Chat”两个显式选项，把压缩决策权交还给用户，这与很多 harness 默默自动摘要的做法不同。

会话持久化：session 以 UUID 标识（在 system/init 消息里出现），支持 -r/--resume 续接、-c/--continue，以及 forkSession: true——fork 会克隆源会话上下文到一个全新独立 session ID，不修改源会话（docs/doc-en_cli_sdk_session-control.md）。

超越”对话记忆”的一层：File Checkpoint & Rewind（docs/doc-en_cli_sdk_checkpoint.md）——enableFileCheckpointing 在每次工具驱动的文件编辑前后做快照，q.rewindFiles(userMessageId, {dryRun}) 可回滚到某个用户回合起始时的文件状态；dryRun 模式只返回 filesChanged/insertions/deletions 统计而不实际改动。明确这是文件状态回滚，不是对话历史回滚，两者独立。

云端 Cloud Agents 的长期记忆是完全不同的机制：Memory Stores（Store→Entry→Version 三层结构，docs/doc-cloud-agents_memory-stores.md），条目是内容哈希 + 乐观并发版本控制（版本冲突返回 409）的纯文本文件，挂载在沙箱内 /data/.qoder/awareness/<entry.path>——agent 本身看到的是一个普通文件系统，完全不感知”memory store”这个 API 概念，这是一个值得记的设计取舍（能力暴露在 API 层，执行层做了透明化）。

另有一个更大颗粒度、CLI 与 Cloud Agents 都可能用到的机制：Repo Wiki（见”自进化能力”一节详述）。

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

CLI 侧工具分类按”功能”而非逐一枚举名称（docs/doc-en_cli_tools.md）：搜索/探索、读、编辑、执行（Bash）、上下文管理（任务跟踪/澄清/记忆/技能/plan 模式）、委派（子agent/workflow/goal/worktree/定时任务）、MCP。可见性控制（--tools、tools.exclude）与执行授权（--allowed-tools/--disallowed-tools、permissions.*）是两条独立的控制面，即”agent 能不能看见这个工具”和”agent 能不能不经批准就用这个工具”分离建模。

MCP 集成（docs/doc-en_cli_mcp-servers.md）：qodercli mcp add/list/remove；4 种传输（stdio/sse/http/ws）；3 种配置作用域（~/.qoder/settings.json 用户级、${project}/.qoder/settings.local.json 项目本地、${project}/.mcp.json 项目共享）；工具名命名空间化为 mcp__<server>__<tool>，支持通配符权限模式（mcp__github__*、mcp__*）。

qoder-action 里能看到的真实 MCP 安装范例：official-repos/qoder-action/scripts/setup-qoder-github-mcp.sh 从 https://download.qoder.com/qodercli/mcp/qoder-github-mcp-server/install.sh 下载独立的 qoder-github-mcp-server 二进制，注册进 ~/.qoder.json 作为 stdio MCP server——这是官方自己的 GitHub 集成也走 MCP 协议、而不是原生内置工具的具体证据。

工具调度实现本身（工具调用如何被闭源二进制解析/路由）不可见。能看到的最接近证据是 ACP demo 客户端的 sessionUpdate 处理器（official-repos/qoder-acp-demos/typescript/src/client/demo-client.ts），它接收的是已经序列化好的 ToolCall 通知，说明 ACP 协议边界之内的解析细节仍在闭源二进制里完成。

Cloud Agents 侧工具注册走版本化字符串（agent_toolset_20260401，docs/doc-cloud-agents_tools.md），显式 allowlist（enabled_tools）；工具目录是 CLI 工具集的严格子集：Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch,DeliverArtifacts；自定义客户端侧工具（type: "custom"，JSON-schema input_schema）永远暂停会话交由客户端执行，不会被自动运行——这是云端产品线为托管沙箱做的显式设计取舍。

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

核心 CLI 的系统提示未见任何泄露/公开版本（闭源二进制，本次也未采集社区仓库 lvzhaobo/qoder-rules 这类可能包含逆向提取内容的非官方来源——已在 NOTES 中标记为”未验证的可能后续来源，需谨慎对待”，本页不采信）。

本次唯一能确认的、官方人类撰写的 prompt 制品是 qoder-action 随附的子agent/命令 Markdown 定义（均为 MIT 许可、面向用户空间，不是闭源核心提示，但体现 Qoder 团队自己的 prompt 工程惯例）：

  • official-repos/qoder-action/.qoder/agents/code-analyzer.md、test-analyzer.md（各约 50 行）：角色框定 + 编号”Core Principles”列表 + 严格 JSON 输出格式契约 + 明确的”Style Guide”节，要求”Plain Text Narrative: Do not use Markdown headers… continuous, conversational explanation”。
  • official-repos/qoder-action/.qoder/commands/review-pr.md、assistant.md：命令级提示，编排上面两个子agent，定义固定小节标题的 Markdown “Summary Template”，并显式禁止元披露（原文：“Never mention ‘sub-agents’, ‘AI tools’, or ‘I cannot run code’”）。assistant.md 还记录了输入参数契约（REPO/BOT_NAME/THREAD_ID 等）和”先发初步回复、再更新”的两阶段交互协议。

动态组装的唯一可核实证据是 AGENTS.md/rules 的注入机制（docs/doc-en_cli_memory.md）——会话启动时或按文件范围匹配规则按需注入，功能上等价于系统提示的动态拼装，但文档没有描述这与核心系统提示字符串如何合并。

子agent 提示 schema 在三个层面结构一致：CLI Markdown frontmatter + 正文、SDK 的 AgentDefinition.prompt 字符串、qoder-action 的 .qoder/agents/*.md——同一套 schema 复用，而非各表一套。

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

这是本次调研文档最详尽的维度，也呈现出一个值得记录的架构特征：Qoder 有三套互不统一的多 agent 机制，而非一套抽象贯穿全场景。

  1. Subagents（docs/doc-en_cli_subagent.md，本次文档信息量最大的单篇）：内置子agent（general-purpose、Explore、Plan、qoder-guide、statusline-setup、SaveMemory）；5 层来源优先级（Built-in < User < Project < Plugin < Flag）；显式调用（“Use the X subagent…“）与隐式调用（description 匹配）并存；--agent 可以让某个子agent直接充当整个 session 的主角色；自然语言可触发多子agent 依次链式调用；Agent(name1,name2) 语法可限制某子agent 自己能再调用哪些子agent；disallowedTools: [Agent] 硬性阻断进一步委派；isolation: worktree 提供文件系统级并行隔离；支持基于 A2A 协议风格 Agent Card（agentCardUrl/agentCardJson + auth: apiKey|http|oauth）的远程子agent。frontmatter 字段全集：background/color/disallowedTools/effort/hooks/initialPrompt/isolation/maxTurns/mcpServers/memory/model/permissionMode/skills/temperature/timeoutMins/tools。
  2. Dynamic Workflows（docs/doc-workflows.md）：一个更重的编排原语，JS 脚本形式（.qoder/workflows/*.js 项目级或 ~/.qoder/workflows/*.js 用户级），提供 agent()/parallel()/pipeline()/phase()/budget 等 helper，作为后台任务运行；脚本本身被沙箱化——workflow 脚本自己没有直接的 shell/fs/network/MCP 权限，只有它 spawn 出的子 agent 才有真实工具权限（仍需过正常的权限/hook 流水线）；导出 meta（name/description/whenToUse/phases）供发现。
  3. Cloud Agents Managed Agents（docs/doc-cloud-agents_managed-agents.md）：第三种、API 原生的云端编排模型——coordinator/child Session-Thread 架构 + 邮箱式线程间消息队列；当 Agent 配置里设置 multiagent.type: "coordinator" 时服务端自动注入 create_agent（异步 fire-and-forget）/Agent（同步阻塞）/send_to_agent（追加消息）/list_agents 工具；child 只拿到一个 send_to_parent 工具；硬性限制：单个 roster 最多 20 个 agent，单 session 最多 25 个并发线程。

三套机制分别服务本地委派、脚本化多阶段扇出、云端 API 原生协调，字段命名和权限模型均不互通，需要在跨 harness 对比时明确标注”这是三套系统”而非”一套统一编排层的三种用法”。

Skill / 插件体系

CLI Skills（docs/doc-en_cli_Skills.md）：目录形式 SKILL.md（YAML frontmatter 仅 name+description，各限 64/1024 字符），发现路径 ~/.qoder/skills/（用户级）或 .qoder/skills/（项目级，覆盖用户级）；两阶段加载——启动时只加载 name+description（低 token 成本的发现阶段），激活时才加载完整正文。文档原话：“Internally, Skills convert to a special Command type and share the same execution mechanism”，即 Skill 底层复用 Command 执行机制，不是独立子系统。

CLI Plugins（docs/doc-en_cli_plugins.md）：更大的打包单位，目录约定含 commands/、agents/、skills/、hooks/hooks.json、output-styles/、bin/、.mcp.json；manifest .qoder-plugin/plugin.json（仅 name 必填）；3 种安装作用域；marketplace 支持 git repo / owner/repo 简写 / 本地目录 / marketplace.json URL 四种来源；插件 hook 会注入 ${QODER_PLUGIN_ROOT}/${QODER_PLUGIN_DATA} 环境变量；明确的安全策略：插件提供的子agent 定义中 hooks/mcpServers/permissionMode 字段会被强制剥离，防止插件通过自带子agent 悄悄提权——这是一个具体、可核实的安全设计点。

Cloud Agents Skills（docs/doc-cloud-agents_skills.md）是独立、更简单的机制：.zip 上传（≤10MB）经 multipart POST /skills，服务端按重新上传自动生成新版本，Agent 总是拿最新版；文档明确标注截至抓取时仍处于 **M2（非 GA）**阶段，不是稳定产品能力，写作时应标注这一点而非当作成熟功能引用。

社区市场（Qoder-AI/qoder-community，Astro 站点）文档显示其技能生态镜像/借鉴了 Anthropic 官方 skills、vercel-labs/skills、mcp-marketplace、skills.sh 的内容（src/content/skillSources/*.md），说明 Qoder 的 Skill 格式设计上是向 SKILL.md 这套跨厂商新兴约定看齐，而非自成一套私有格式。

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

本维度最值得记录的发现是 Dreams（docs/doc-cloud-agents_dreams.md），Qoder 最具原创性的功能：一种异步”记忆巩固”作业，启动一个专门的内部”Dreaming Agent”读取近期会话历史，对某个 Memory Store 做合并/剪枝/补充。具体安全设计（均为文档原文描述，非源码可核实，但描述具体到可操作细节）：

  • 写时复制（copy-on-write）：输入 store 从不被直接修改，永远克隆到一个新的输出 store；
  • 最小权限：Dreaming Agent 只能使用 memory/session_list/session_read 三个工具——无代码执行、无网络；
  • 单飞（single-flight）：同一用户同时只能有一个 Dream 在跑，重复触发返回 409；
  • 典型运行时长 1–5 分钟。

这在概念上类似”sleep-time compute”/离线记忆巩固这类研究方向，但是作为一等产品 API 直接对外提供，而非仅停留在论文/内部实验层面——这一点值得在跨 harness 对比时特别标注。

次一级的自进化模式是 Repo Wiki（docs/doc-user-guide_repo-wiki.md）：自动生成、持续同步的项目架构文档，用作长期上下文，使”某功能是怎么实现的”这类问题几乎零工具调用即可回答；三种再生成触发方式（初次生成/检测到代码漂移/git 目录同步）；人类编辑受保护——人工修正会”reverse-synced 到 knowledge cards”，不会被下一次自动更新静默覆盖。这是一种粗粒度、人类主导（而非自动 eval 驱动）的纠错闭环。

未发现任何自动化 eval 套件驱动自我改进的公开证据（例如内部 benchmark harness 反馈进模型/提示更新）——文档未披露，闭源二进制外部也无法观测，记为”未公开/未发现”。

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

CLI 侧最主要的可观测性接缝是 hook 系统本身（docs/doc-en_cli_hooks.md）：22 个生命周期事件（SessionStart/SessionEnd、UserPromptSubmit、PreToolUse/PostToolUse/PostToolUseFailure、PermissionRequest/PermissionDenied、Stop/StopFailure、SubagentStart/SubagentStop、PreCompact/PostCompact、Notification、InstructionsLoaded、ConfigChange、CwdChanged、FileChanged、WorktreeCreate/WorktreeRemove、Elicitation/ElicitationResult），每个都有文档化的 stdin/stdout JSON schema。事件里带的 transcript_path 字段证实每个 session 有一份持久化的、基于文件的会话记录，但其确切格式对 hook 作者是不透明的（只给路径，不给 schema）——这是文档明确留白的一点。InstructionsLoaded（记忆文件加载事件）和 ConfigChange（配置变更事件）是审计导向的细节事件，未见其他同类 harness 有对等文档化事件，值得记一笔。

面向 CI/自动化的可观测性：stream-json 输出格式（行分隔 JSON，system/init → session_id，assistant/message → text/thinking/tool-call parts），在 official-repos/qoder-action/scripts/qoder-wrapper.js 里被具体解析和渲染——这是本次唯一能读到实际解析代码的地方；该文件还展示了 ACTIONS_STEP_DEBUG 门控原始工具参数可见性，以及一个 maskSensitiveData() 函数对匹配 token|password|secret|key|auth|credential|private|cert|access_key 的字段做递归脱敏。

Cloud Agents 的可观测性是完全独立的一套：类型化 SSE 事件流（agent.tool_use/agent.mcp_tool_use/agent.custom_tool_use/session.status_idle/session.thread_created 等），配游标分页的历史接口（list_events/list_thread_events）——是比 CLI 文件式 transcript 更结构化的正式事件 API。

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

这是文档覆盖第二详尽的维度（docs/doc-en_cli_permissions.md）：

  • 5 种权限模式：default/accept_edits/auto/bypass_permissions/dont_ask；另有 Plan/Goal 两种”工作状态”叠加在权限模式之上。
  • 8 层设置优先级：user → project → local → --settings → CLI args → /allow//deny → session-temp（自上而下覆盖关系）。
  • 精确的决策顺序：deny 规则 → 工具自身硬编码的安全检查（如危险命令检测）→ ask 规则 → allow 规则/模式自动放行 → 环境相关的 ask 具体解析方式（TUI 弹窗 / headless 自动拒绝 / SDK canUseTool 回调 / ACP requestPermission RPC）。
  • 信任目录模型：默认只信任启动时的 CWD；在非受信目录下，非 default 权限模式会被静默降级回 default；一份固定的”受保护路径”清单（.git、.vscode、.husky、shell rc 文件、.mcp.json 等）即便在宽松模式下也需要显式批准，在 auto 模式下则被无条件拒绝。
  • hook 权限覆盖是架构上最强的一层：PreToolUse hook 返回 deny 会覆盖即使是 bypass_permissions/YOLO 模式——文档原文明确描述为面向组织安全策略的”unbypassable interception”，即这是刻意设计成用户不能通过切换权限模式绕过的硬策略层。配套的 disableYoloMode: true（组织策略）还会彻底关闭 YOLO 模式的所有入口（命令行 flag、快捷键，甚至把请求 bypassPermissions 的子agent 强制降级为 acceptEdits）。

密钥/凭据处理的具体可核实证据来自 qoder-action：official-repos/qoder-action/scripts/configure-qoder-auth.sh 做 OIDC token → Qoder token 交换；GitHub token 通过 ::add-mask:: 从不打印明文；qoder-wrapper.js 的 maskSensitiveData()（见上节）在日志记录工具调用参数前做嵌套对象脱敏。

Cloud Agents 有一套并行的权限系统（docs/doc-cloud-agents_permission-policies.md）：permission_policy（always_allow/always_ask/always_deny）配置在 Agent 对象本身（而非每个 session），ask 的待处理动作会无限期暂停整个 session（无自动超时），直到客户端提交 user.tool_confirmation。

沙箱与执行隔离

CLI 侧的主要隔离原语是git worktree（--worktree [name] 会话级 / isolation: worktree 子agent级），本质是隔离工作目录而非完整的 OS/VM 沙箱——进程仍在用户机器上以正常 OS 权限运行，只受上面权限/hook 层的约束，没有发现任何 seccomp/容器/VM 级隔离的文档描述。

--remote/Cloud Mode（docs/doc-en_cli_cloud-mode.md）把执行整体转移到 Qoder 托管的云端 VM，本地终端只是一个流式客户端——这里确实存在真正的机器边界隔离，但需要记录一个操作层面的坑：本地 Ctrl+C 在 --remote 模式下只是断开终端订阅，不会停止云端任务，用户可能误以为已经杀掉任务。

Cloud Agents 平台的 Session 运行在”隔离容器沙箱”中（文档原文：“Each Session runs in an isolated container sandbox; Sessions cannot reach one another. Data is wiped when the environment is destroyed”，docs/doc-cloud-agents_overview.md），另有独立的 Environment 对象控制容器类型/网络策略/预装依赖（cloud-agents/environments、container-reference 文档索引中列出但本次未深读，留作后续）。Dreams 的 Dreaming Agent 本身也算一种微型沙箱策略——通过工具集裁剪（无代码执行、无网络）实现权限隔离，而非独立的执行环境。

没有找到任何关于 Cloud Agents 容器具体沙箱技术（gVisor/Firecracker/Docker 等）的公开说明——明确记为”未披露”，不做猜测。

与模型的协同设计

ModelPolicyProvider 回调（SDK，docs/doc-en_cli_sdk_model-policy.md）允许按请求做模型路由，回调 key 是 context.purpose（main/subagent/compact/WebFetch/图像生成等），可返回命名模型档位（lite/efficient/performance/ultimate/auto）或完整的 BYOK 凭据对象（{provider, model, api_key}）将单次请求路由到第三方模型提供商。明确没有自动 fallback——回调抛错/超时/返回空值会导致整次查询失败，调用方需要自己在回调内部实现兜底逻辑，这是一个值得记录的运维风险点。模型/推理强度也可按请求通过 parameters: {contextWindow, reasoningEffort} 微调，可用范围通过运行时查询的 ModelInfo.context_config/thinking_config 元数据暴露（q.getAvailableModels()）。

产品本身明确是多模型的：文档示例中出现通过 bailian（阿里百炼）provider 调用 qwen3.5-plus-cp 的 BYOK 范例，营销侧文档索引（llms.txt）还出现”Qwen3.7-Max”相关页面——这把 Qoder 定位为一个坐在（至少）阿里自家 Qwen 系列 + BYOK 第三方模型之上的 harness，而不是像 Claude Code 与 Claude 那样与单一模型深度绑定协同设计的配对。

未发现任何训练时协同设计的公开披露（无 RL-on-tool-use、无 agent 专属微调细节）——未公开记录。

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

未找到任何公开文档描述 session 轨迹被反馈进模型训练或内部 eval 套件。最相关的两个邻近机制：

  • Dreams 会读取会话历史（session_list/session_read 工具），但目的仅是巩固面向用户的记忆 store，不是生产训练数据（docs/doc-cloud-agents_dreams.md）。
  • File Checkpoint/Rewind 与 session fork 保留的是交互式撤销/分支所需的轨迹状态，不是为离线分析或再训练设计（docs/doc-en_cli_sdk_checkpoint.md、docs/doc-en_cli_sdk_session-control.md）。

Cloud Agents 的 Session Event Stream API（list_events/stream_events）通过 HTTP/SSE 暴露完整的结构化轨迹，理论上可以被阿里内部拿去做 eval/训练用途，但没有任何公开声明证实这一点，断言这一点会是猜测——本页记为”未发现/未披露”。

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

  1. 三套互不统一的多 agent 编排机制（Subagents / Dynamic Workflows / Cloud Agents Managed Agents）并存，而非一套抽象贯穿本地和云端——这与很多单一编排层的 harness 形成对比，留待 synthesis 阶段量化”统一 vs 分裂”这条轴。
  2. Dreams（写时复制、最小权限、单飞的异步记忆巩固 agent）是本次调研中最具原创性的自进化机制，概念上呼应”sleep-time compute”研究方向但已作为一等产品 API 交付，值得作为跨 harness “自进化能力”维度的标杆案例。
  3. hook 权限覆盖严格强于 YOLO/bypass 模式——多数 harness 的”最高权限模式”就是最高权限，Qoder 把组织级 hook 策略放在权限模式之上，这是一个明确、可核实的安全模型设计取舍，可作跨 harness 安全模型对比的一个具体锚点。

原始源码定位

  • repo: 无公开源码（核心 qodercli 闭源 npm 包 @qoder-ai/qodercli）；辅助官方仓库：
    • github.com/QoderAI/qoder-action
    • github.com/QoderAI/qoder-acp-demos
    • github.com/Qoder-AI/qoder-community（注意大小写）
  • commit/version analyzed:
    • qodercli: 0.1.18（仅从 qoder-action/action.yml pin 值推断，非独立核实的官方 release）
    • qoder-action: 0881d27d15a7a93778ebc5c942d11da313ee8b7e
    • qoder-acp-demos: 3915960f9472a6d38560d226bb2ec7ba619d986d
    • qoder-community（Qoder-AI 组织）: 9d67b44cdca0cedae2067759d5d5bff9c0004a45
    • QoderAI/skills: a028ed30b12deb53861c06f652b86c8a91798eee（空占位仓库，仅供记录，非有效来源）
  • 关键文件列表（相对 sources/harness/alibaba-qoder/ 路径）：
    • official-repos/qoder-action/action.yml
    • official-repos/qoder-action/scripts/qoder-wrapper.js
    • official-repos/qoder-action/scripts/run-qodercli.sh
    • official-repos/qoder-action/scripts/configure-qoder-auth.sh
    • official-repos/qoder-action/scripts/setup-qoder-github-mcp.sh
    • official-repos/qoder-action/.qoder/agents/code-analyzer.md
    • official-repos/qoder-action/.qoder/agents/test-analyzer.md
    • official-repos/qoder-action/.qoder/commands/review-pr.md
    • official-repos/qoder-action/.qoder/commands/assistant.md
    • official-repos/qoder-action/docs/recipes.md
    • official-repos/qoder-acp-demos/typescript/src/main.ts
    • official-repos/qoder-acp-demos/typescript/src/acp/session.ts
    • official-repos/qoder-acp-demos/typescript/src/qodercli/spawn.ts
    • official-repos/qoder-acp-demos/typescript/src/client/demo-client.ts
    • official-repos/qoder-acp-demos/typescript/src/client/elicitation.ts
    • official-repos/qoder-acp-demos/typescript/src/client/filesystem.ts
    • official-repos/qoder-acp-demos/typescript/docs/integration-guide.md
    • official-repos/qoder-acp-demos/typescript/docs/troubleshooting.md
    • official-repos/qoder-community-templates/AGENTS.md
    • official-repos/qoder-community-templates/coding-agent-SKILL.md
    • official-repos/qoder-community-templates/skill-frontmatter-template.md

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/alibaba-qoder/ 下：

  • NOTES.md — 上一阶段调研员的完整 recon 笔记（本页所有论断的直接依据）
  • official-repos/qoder-action/ — 官方 GitHub Action 仓库克隆（含 .qoder/agents、.qoder/commands、scripts/、docs/）
  • official-repos/qoder-acp-demos/ — 官方 ACP TypeScript 参考客户端克隆
  • official-repos/qoder-community-templates/ — Qoder-AI/qoder-community 仓库中与本调研相关的模板/范例文件
  • docs/ — 26 篇 docs.qoder.com 官方文档，.md 格式：
    • CLI: doc-using-cli.md、doc-workflows.md、doc-en_cli_memory.md、doc-en_cli_permissions.md、doc-en_cli_tools.md、doc-en_cli_subagent.md、doc-en_cli_plugins.md、doc-en_cli_hooks.md、doc-en_cli_mcp-servers.md、doc-en_cli_acp.md、doc-en_cli_cloud-mode.md、doc-en_cli_Skills.md、doc-en_cli_model.md
    • SDK: doc-en_cli_sdk_agents.md、doc-en_cli_sdk_checkpoint.md、doc-en_cli_sdk_model-policy.md、doc-en_cli_sdk_session-control.md、doc-en_cli_sdk_permissions.md
    • Cloud Agents: doc-cloud-agents_overview.md、doc-cloud-agents_memory-stores.md、doc-cloud-agents_dreams.md、doc-cloud-agents_managed-agents.md、doc-cloud-agents_permission-policies.md、doc-cloud-agents_tools.md、doc-cloud-agents_skills.md
    • 用户指南: doc-user-guide_repo-wiki.md、doc-user-guide_chat_smart-context-control.md

未完成的后续调研线索（据 NOTES.md 第 3 节，本页未采信，仅记录供后续追加）：lvzhaobo/qoder-rules（非官方、未验证的社区仓库，可能含逆向提取的系统提示相关内容）；docs.qoder.com/cloud-agents/environments 与 container-reference（沙箱技术细节）；QoderWake 产品线（独立的”数字员工”产品，有自己的 Memory System 和 WakerFlow 多 agent 引擎，docs.qoder.com/qoderwake/*）。

关系图谱

反向链接