AI Research 技术调研

Amazon Q Developer：闭源 IDE /dev agent + 一手可查的开源 Rust CLI（现已 fork 为闭源 Kiro CLI）

23分钟阅读

Amazon Q Developer

一句话定位

“Amazon Q Developer” 是一个品牌伞，下面至少有两个技术上完全不同的 agent 实现： (1) IDE 扩展（VS Code/JetBrains/Visual Studio）里的 /dev 特性开发 agent，用 textcode 框架，闭源，逻辑全在服务端，客户端仓库 aws/aws-toolkit-vscode 只是 一个瘦身 webview/API client；(2) 一个真正开源过的终端 agent CLI （q chat/qchat），github.com/aws/amazon-q-developer-cli 的 Rust workspace， 这才是本 dossier 大部分技术细节的来源。该仓库 README 明确写着”不再积极维护， 现已作为闭源产品 Kiro CLI 提供”——所以这是一份历史快照，不是当前在售产品的 实时源码。

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

分析基于 aws/amazon-q-developer-cli commit 15cc8f3cd18c4272925ce1c7053268eedff1ea0a （2026-04-23 14:17:15 -0700，2026-07-07 浅克隆）。仓库内并存两套 agent 实现：

amazon-q-developer-cli/
├── crates/chat-cli/           — 生产/在售版本（q chat 实际跑的代码）
│   └── src/cli/chat/
│       ├── mod.rs             — ChatSession, ChatState 枚举, next() 驱动循环 (4699 行)
│       ├── conversation.rs    — ConversationState, 压缩 prompt, tangent mode (1754 行)
│       ├── tool_manager.rs    — 工具注册装配（原生 + MCP）(2205 行)
│       ├── tools/
│       │   ├── mod.rs         — Tool 枚举, NATIVE_TOOLS
│       │   ├── delegate.rs    — 子 agent "Delegate" 工具 (602 行)
│       │   └── execute/mod.rs — execute_bash 工具、危险命令检测 (750 行)
│       ├── checkpoint.rs      — shadow git repo 快照 (489 行)
│       └── cli/agent/         — Agent(声明式配置)、hook.rs
│   └── src/{auth,database,api_client,telemetry,logging}/
├── crates/agent/               — 新的、从头重写的 agent crate（本快照里似乎尚未
│                                  接管为默认实现，疑似是 ACP 对齐的后继版本）
│   └── src/agent/
│       ├── mod.rs             — Agent v2, ExecutionState 枚举 (2195 行)
│       ├── agent_loop/mod.rs  — LoopState/LoopEndReason 枚举 (731 行)
│       ├── permissions.rs     — evaluate_tool_permission() (314 行)
│       ├── agent_config/definitions.rs — 版本化 AgentConfig (如 V2025_08_22)
│       ├── tools/             — grep/glob/ls/mkdir/rm/image_read/execute_cmd/mcp.rs
│       └── mcp/                — 独立 MCP-server-manager actor
├── docs/                        — 官方一手技术文档（随仓库版本管理，非第三方博客）：
│                                  hooks.md, built-in-tools.md, default-agent-behavior.md,
│                                  experiments.md, knowledge-management.md 等
├── schemas/agent-v1.json        — agent 配置文件的 JSON Schema (draft-07)
└── terminal-bench-test/main.py  — Terminal-Bench 评测适配器 (51 行)

IDE /dev agent 的信息全部来自两篇 AWS 官方博客（无源码）：

  • 2024-06《Reimagining software development with the Amazon Q Developer agent》(AWS ML Blog)
  • 2024-09《Reinventing the Amazon Q Developer agent for software development》(AWS DevOps Blog， 即任务种子链接)

aws/aws-toolkit-vscode（commit 6cf61e7ebaf4047948c240ed48e98890e758e304）中 packages/core/src/shared/clients/qDeveloperChatClient.ts、codewhispererChatClient.ts 经检索确认只是基于 AWS SDK v3 的流式 API 客户端，注释自述”Create a client for featureDev streaming based off of aws sdk v3”——真正的 explore/plan/act 推理循环在 服务端执行，客户端仓库里没有。

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

chat-cli（在售生产版）：显式状态机 ChatState 枚举 （PromptUser/HandleInput/ValidateTools/ExecuteTools/HandleResponseStream/ CompactHistory/RetryModelOverload/Exit，crates/chat-cli/src/cli/chat/mod.rs:1281-1309）。 驱动循环：while !matches!(self.inner, Some(ChatState::Exit)) { self.next(os).await?; } （mod.rs:1482-1484）。next()（mod.rs:823-919）按状态分派，每个分支用 tokio::select! 与 ctrl-c 通道竞争以支持中断。工具循环在 tool_use_execute() （mod.rs:2366+）：逐工具检查权限、需要则请求确认，否则执行并回到 ChatState::HandleResponseStream 再次进入模型——隐式的”直到模型不再产生 tool_uses 才停”模式，与官方博客”agent 在生成合适改动后退出循环”的通俗描述一致。

新 agent crate（重写版，疑似 ACP 对齐）：更清晰的显式状态机——LoopState 枚举（Idle → SendingRequest → ConsumingResponse → {PendingToolUseResults | UserTurnEnded | Errored}，crates/agent/src/agent/agent_loop/mod.rs:93-113）。 回合结束条件显式定义：LoopEndReason::UserTurnEnd = “循环结束是因为模型返回了 不带 tool use 的响应”（agent_loop/protocol.rs:243-244）；其余结束原因： DidNotRun、ToolUseRejected、Error、Cancelled。

IDE /dev agent（仅博客，无源码）：官方描述为”explore → act → evaluate”循环： 探索工作区、提议/执行工具操作，“有防止陷入无效路径的逻辑”，agent 自行判断改动 （含测试/文档）是否充分后退出循环、把补丁交回用户审阅；用户反馈后重新进入循环。 未公开具体的迭代上限或更细机制。

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

  • 压缩：ConversationState::create_summary_request() （crates/chat-cli/src/cli/chat/conversation.rs:630-728）构造一条显式的 “[SYSTEM NOTE: automated summarization request]” 提示，要求模型输出结构化 要点摘要（话题、已执行工具+结果、代码/技术信息、关键洞见、活跃 TODO 列表 ID）， 并要求”用第三人称……不是直接回应”。触发方式：API 报 ContextWindowOverflow 时自动触发（mod.rs 约第 990-1021 行），或手动 /compact。CompactStrategy 控制 truncate_large_messages/max_message_length/messages_to_exclude。
  • 会话持久化：本地 SQLite（rusqlite+r2d2_sqlite），conversations 表 + state 表（database/mod.rs），迁移脚本如 007_conversations_table；会话按 文件系统路径寻址（get_conversation_by_path/set_conversation_by_path）。
  • 跨会话长期记忆：独立的 semantic-search-client Rust crate——本地 embedding（ONNX/candle 后端，macOS 上 Metal 加速），双索引类型：BM25（“Fast”） 与向量 embedding（“Best”，all-MiniLM-L6-v2），见 docs/knowledge-management.md。 每个 agent 独立的知识库目录 ~/.aws/amazonq/knowledge_bases/<agent>_<hash>/。 实验性、默认关闭（chat.enableKnowledge）。
  • 会话分支：“Tangent Mode” 实验特性——快照对话、探索侧支线话题、再返回主线 （conversation.rs: enter_tangent_mode/exit_tangent_mode）。
  • 工作区状态快照（区别于对话记忆）：CheckpointManager（checkpoint.rs） 把文件变更快照进每会话的 shadow bare git repo；/checkpoint list/expand/diff/restore/clean。
  • IDE /dev agent：博客称 textcode 框架给 agent 提供”代码、代码文件、代码工作区的 token 高效文本表示”，从而”保留关键信息……同时丢弃不影响理解的冗余代码”——即上下文 管理靠一套自定义的文本化虚拟 IDE 抽象，公开信息未再深入。

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

  • 原生 Tool 枚举（tools/mod.rs:92-104）：FsRead, FsWrite, ExecuteCommand, UseAws, Custom(MCP), GhIssue, Introspect, Knowledge, Thinking, Todo, Delegate。 NATIVE_TOOLS 常量列出 9 个始终可用的工具（tools/mod.rs:74-87）。
  • 每个 Tool 变体实现 requires_acceptance()（权限门）、invoke()（执行）、 queue_description()（执行前渲染人类可读预览）、validate()。
  • MCP 工具包装为 Tool::Custom(CustomTool)；ToolOrigin::McpServer(String) 在 发给模型的工具 spec 中区分原生/MCP 来源（tools/mod.rs:266-270）。
  • MCP 客户端（mcp_client/client.rs）构建在官方 rmcp crate 之上；传输方式： stdio（子进程）或 HTTP（schemas/agent-v1.json 的 TransportType）。
  • 新 agent crate 扩展了内建工具集：新增 Grep、Glob、Ls、Mkdir、Rm、 ImageRead、SpawnSubagent 作为独立的 BuiltInTool 变体 （crates/agent/src/agent/tools/*.rs）——说明重写版把 legacy chat-cli 里较 粗粒度的工具（fs_read/fs_write/execute/use_aws 等）拆得更细。
  • 工具别名（agent 配置里的 toolAliases）允许用户重映射工具名。
  • execute_bash：基于模式的风险检测（DANGEROUS_PATTERNS：反引号、$()、重定向、 &&、;、$ 等，tools/execute/mod.rs:60-71），除一小撮 READONLY_COMMANDS 白名单（ls, cat, echo, pwd, which, head, tail, find, grep, dir, type）外一律 强制确认。

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

  • 系统提示对应字段：Agent.prompt / Agent.system_prompt（跨版本别名 prompt/system_prompt）——用户或组织自定义，从 agent 配置 JSON 加载，源码 注释明确说”与系统提示同一范畴的上下文”（cli/agent/mod.rs:140-143）。支持 内联文本或 file:// URI。
  • 动态组装：format_user_context_message()（agent/mod.rs:1760+）把 system_prompt + 资源文件内容 + agent-spawn-hook 输出拼接进随首轮发送的上下文 消息。
  • 默认自动注入的资源文件：AmazonQ.md、README.md、.amazonq/rules/**/*.md （docs/default-agent-behavior.md）。
  • 压缩提示（见”记忆”节）是一段独立、措辞严格的命令式模板——可看出 Amazon 专门 调过具体措辞以对抗模型”用对话语气回应摘要请求”的倾向。
  • IDE /dev agent：未公开系统提示文本，博客只说 agent “以问题陈述初始化，并附带 一些如何解决问题、如何使用其配备工具的指引”，无更多公开细节。

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

子 agent 是真实存在的，且有两套并行实现：

  • Legacy chat-cli：Delegate 工具（tools/delegate.rs）——launch_agent() → spawn_agent_process() 实际是 tokio::process::Command::new("q") .args(["chat","--non-interactive", ..., "--agent", agent_name, task])，作为 脱离的操作系统子进程启动（Unix 上 process_group(0)），异步监控，执行完由 LLM 生成 2-3 句摘要（generate_summary()）回填父会话上下文。状态/结果以 JSON 文件存于 .amazonq/.subagents/。实验性，默认关闭（chat.enableDelegate）。
  • 新 agent crate：子 agent 是进程内一等概念—— Agent.execution_state.executing_subagents: HashMap<AgentId, Option<String>>， 且 BuiltInTool::SpawnSubagent 是独立内建工具（不是”套壳调子进程”的 wrapper 工具）——暗示重写版把子 agent 编排从”shell 出另一个 CLI 实例”改为”同进程内 管理子 agent 状态”。
  • 未发现能自动把任务拆解成多个并行顶层 agent 的规划器/路由器——委派是 用户/模型逐任务触发、一次一个命名 agent（源码注释：“Only one task per agent”）。
  • IDE /dev agent：未公开任何多 agent 编排；单 agent、单一 explore→act→evaluate 循环。

Skill / 插件体系

  • “Agent” 配置文件本身就是技能/插件单元：具名、版本化（$schema，如 2025_08_22），JSON 文件位于 .amazonq/cli-agents/（本地）或 ~/.aws/amazonq/cli-agents/（全局）（docs/default-agent-behavior.md）。 每个 agent 配置声明自己的系统提示、允许的工具+别名、工具专属设置、资源 （上下文文件）、hooks、MCP servers——功能上等价于一个”技能包”。
  • MCP servers 是新增全新工具的扩展机制（stdio 或 HTTP 传输，逐 server 配置在 mcpServers）。
  • 源码中未发现独立的”技能市场”或发现机制（不同于例如 Claude Code 的 Skill 目录）——扩展纯靠本地/全局 agent-config JSON 文件 + MCP server 配置。

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

  • 源码中未发现自主的自我改进/自我修改提示机制。
  • 最接近的类比：
    • knowledge 工具 = 持久化、用户自行整理的长期记忆（不是模型基于结果自主写入， 而是用户显式运行 /knowledge add）。
    • Hooks（PostToolUse、Stop）允许用户自定义脚本在工具调用后/回合结束时运行做 校验/格式化，但这是用户自定义自动化，不是模型驱动的自我纠错。
    • ChatState::RetryModelOverload 是弹性重试机制，不是学习。
  • SWE-bench 提交节奏（SWE-bench/experiments 元数据显示 2024-04 至 2025-04 间 5 个带日期的 dev 版本）说明底层模型/agent 由 Amazon 团队基于基准分数做离线迭代， 但这属于标准工程迭代（仅以版本号变化体现），源码中未发现产品内的 eval 驱动自我纠错闭环。
  • IDE /dev agent：博客明确把 2024 年 9 月的整次重设计描述为”数十次实验的成果”—— 即离线实验驱动了重设计，而非在线/自主的自我进化循环。

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

  • 标准 Rust tracing crate：logging.rs 配置 EnvFilter + 文件/stdout subscriber，日志轮转（MAX_FILE_SIZE = 10MB），可热重载的 filter handle。 /logdump CLI 命令（cli/chat/cli/logdump.rs，238 行，仅列出未全读）推测用于 导出/打印日志。
  • 遥测：独立的结构化事件系统——telemetry/core.rs（835 行）定义类型化事件构建器 （AgentConfigInitArgs、ChatAddedMessageParams、RecordUserTurnCompletionArgs、 ToolUseEventBuilder 等），通过 AWS 自家 amzn-toolkit-telemetry-client crate 发往 StaticEndpoint，用 CognitoProvider（匿名 identity pool）鉴权——即产品 分析遥测，独立于、且额外于对话/工具日志。use_aws 调用有逐工具遥测 （tool_use_telemetry_events）追踪 accepted/trusted/duration/AWS 服务名。
  • 未发现分布式追踪/OpenTelemetry span 格式；遥测是离散命名事件，不是 trace 树。

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

  • 核心抽象：PermissionEvalResult（Allow | Ask | Deny{reason}），针对每次工具 调用，依据当前 Agent 配置评估（tools/mod.rs: requires_acceptance()，新 crate 里的 agent/permissions.rs: evaluate_tool_permission()）。
  • 细粒度逐工具设置（docs/built-in-tools.md）：execute_bash —— allowedCommands/deniedCommands（正则，锚定 \A...\z）、autoAllowReadonly、 denyByDefault；fs_read/fs_write —— allowedPaths/deniedPaths （gitignore 风格 glob）；use_aws —— allowedServices/deniedServices、 autoAllowReadonly。deny 规则总是先于 allow 规则评估。
  • 默认信任：fs_read 和 report_issue（gh_issue）开箱即信任；execute_bash、 fs_write、use_aws 默认需确认（除非另行配置）。
  • Hooks 作为安全控制面：PreToolUse hook 可返回退出码 2 硬阻断工具调用， STDERR 文本作为拒绝理由回传给模型（docs/hooks.md:102-105）——即 hooks 是 Amazon 用来让组织注入安全策略（如一个 validate-tool.sh 脚本）的机制，不只是 日志。
  • --trust-all-tools 标志（见于 delegate.rs 子进程调用和 terminal-bench-test/main.py）完全绕过审批门——用于 CI/基准测试/非交互自动化， 且当 delegate 任务不带命名 agent 运行时源码里有显式警告 （“Tasks without an agent (default) run with trust-all permissions and show a warning”，docs/experiments.md:145）。
  • 内容/遥测退出机制：X-Amzn-CodeWhisperer-OptOut HTTP 头，由 Setting::ShareCodeWhispererContent 逐请求设置（api_client/opt_out.rs）—— 控制请求内容是否可被 Amazon 用于服务改进（这是 AWS 企业版”不要用我的代码训练” 控制项，与 CodeWhisperer/Q 的 IDE 产品同一机制）。默认是 opt-out 而非 opt-in （unwrap_or(true)，即默认允许分享，除非用户/组织显式关闭）。
  • 认证：AWS SSO OIDC device-authorization/PKCE 流程，对接 AWS IAM Identity Center 或 “Builder ID”（auth/builder_id.rs、auth/pkce.rs）——客户端不存静态长期 API key，只有短期 OAuth token。

沙箱与执行隔离

  • 未发现沙箱。 execute_bash/ExecuteCommand::invoke() 直接在宿主 OS 上跑 （原生 std::process/tokio::process::Command），只靠上述模式匹配权限系统 把关——生产代码路径里没有容器、chroot-jail、seccomp 或 VM 隔离。
  • 唯一发现的 Chroot 抽象（os/fs/mod.rs）是测试夹具（tempdir 支撑的 Fs 枚举变体，仅在单元测试中使用，所有调用点均确认在 #[cfg(test)]/assert_eq! 上下文中）——不用于真实命令执行。
  • Terminal-Bench 集成（terminal-bench-test/）依赖Terminal-Bench 自身的 Docker 容器做隔离，不是 Amazon Q 自己提供的——agent 只是被安装并运行在基准测试 harness 管理的容器内。
  • Checkpointing（shadow git repo）提供的是撤销而非隔离——不能阻止破坏性命令 执行，只能在事后帮忙回滚文件层面的副作用。

与模型的协同设计

  • 后端是 Amazon 私有服务（代码注释/模块名中内部称 “RTS” —— Runtime Service， 即 agent/rts/mod.rs），API 形状紧贴 AWS Bedrock 的 Converse/ConverseStream 协议（api_client/model.rs 中的 ChatResponseStream、ToolUse/ToolResult、 AssistantResponseMessage）。
  • 模型选择是动态的、由服务端驱动：ModelInfo::from_api_model() 从 amzn_codewhisperer_client 后端返回的列表中取 model_id、description、 model_name、context_window_tokens（来自 token_limits().max_input_tokens()）——CLI 不写死单一基础模型，用户可通过 /model 在后端提供的模型间切换。
  • 源码中未发现具体是哪个/哪些基础模型在驱动响应（Amazon 自研还是授权 Claude 等）——这是后端实现细节，客户端不暴露。
  • IDE /dev agent（textcode 框架）：博客将其”模型协同设计”的核心洞见描述为 刻意放弃截图/可视化 IDE 式交互（理由是当前 LLM 在密集图像上保真度弱），转而 采用全文本的”面向 LLM 的 IDE”抽象——即框架是围绕已知的 LLM 模态强项（文本远强 于图像）设计的，而非模仿人类的可视化工作流。无更多公开实现细节。

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

  • SWE-bench：Amazon 向 SWE-bench/experiments 提交了 5 个带日期的 dev-agent 版本（2024-04-30-dev、2024-07-19-dev、2024-12-02-dev、2025-04-05-dev，另有一个 nova-premier 条目）——证实 Amazon 把 SWE-bench 当作模型/agent 变更前后的 经常性内部评测门槛，即 trajectory 被捕获并用于离线评测，不必然是训练。
  • Trajectory 公开可达性：博客声称”我们很自豪能分享最新 agent 的 trajectory” 并链接到一个 GitHub 路径（evaluation/verified/20240721_.../trajs）——该路径 在当前仓库中已不存在（经 GitHub UI 和 git clone + find 双重确认 404）。 每个 Amazon Q Developer Agent 提交的 metadata.yaml 中，trajectory 实际存放在 assets.trajs: s3://swe-bench-submissions/...，即 trajectory 一直（现在也） 托管在私有 S3 bucket 上，由 SWE-bench 自己的站点代理展示，并非直接可在 git 仓库里浏览的文件——博客”在 GitHub 上”的表述不精确；更准确的说法是”记录在 SWE-bench experiments 追踪仓库里，后端是非公开 S3 bucket”。未能取回实际 trajectory JSON 内容（匿名 HTTPS GET 该 S3 bucket 返回 404/无公开列表）。
  • 产品层面的 opt-out 信号：X-Amzn-CodeWhisperer-OptOut 头 （api_client/opt_out.rs）是最清晰的证据，证明用户对话/工具使用内容默认（是 opt-out 不是 opt-in——unwrap_or(true) 意味着默认开启分享，除非用户禁用）可被 Amazon 用于”改进服务”（标准 CodeWhisperer/Q Developer 数据使用措辞）——暗示 生产环境的使用会话确实反哺某种改进管线（很可能是评测/训练数据整理），除非 组织/用户 opt out。
  • 源码层面未发现自动化的”trajectory → 训练样本”管线证据（符合预期——那应该完全 在服务端/Amazon 内部基础设施里，不在这个客户端仓库中）。

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

  1. “两套并存的 agent 实现 + 品牌下两种开放程度”是本 harness 最独特之处： IDE 面向的 /dev agent（textcode 框架）完全闭源、逻辑在服务端；terminal 面向的 CLI 则短暂开源过、且仓库内部自身又并存 legacy chat-cli（生产在售） 与重写中的 agent crate（新状态机、进程内子 agent、更细粒度工具）两代实现， 这种”一手可查但即将/已经收回”的状态在已调研的其它 harness 中少见。
  2. 子 agent 委派从”shell 出一个完全独立的 q chat 子进程”（legacy）演进到 “进程内一等状态管理”（新 agent crate），体现了从”CLI 套壳 CLI”到”原生 多 agent 运行时”的架构方向。
  3. 沙箱与轨迹利用两个维度均”官方未真正兜底”：execute_bash 直接跑在宿主 OS 上无隔离；SWE-bench 轨迹的”公开可查”承诺（博客原话）与实际（私有 S3、 404）不符，这两点都需要在跨 harness 对比时如实标注为弱项而非营销话术。

原始源码定位

  • repo: https://github.com/aws/amazon-q-developer-cli（README 自述已不再积极维护， 现作为闭源 Kiro CLI 提供）；另参照 https://github.com/aws/aws-toolkit-vscode （仅用于确认 IDE /dev agent 客户端无服务端逻辑）
  • commit/version analyzed: 15cc8f3cd18c4272925ce1c7053268eedff1ea0a（2026-04-23 14:17:15 -0700，2026-07-07 浅克隆时的 HEAD）；aws-toolkit-vscode 侧为 6cf61e7ebaf4047948c240ed48e98890e758e304（2026-07-06）
  • 关键文件列表（相对 amazon-q-developer-cli 仓库根目录）：
    • crates/chat-cli/src/cli/chat/mod.rs
    • crates/chat-cli/src/cli/chat/conversation.rs
    • crates/chat-cli/src/cli/chat/tool_manager.rs
    • crates/chat-cli/src/cli/chat/tools/mod.rs
    • crates/chat-cli/src/cli/chat/tools/delegate.rs
    • crates/chat-cli/src/cli/chat/tools/execute/mod.rs
    • crates/chat-cli/src/cli/chat/checkpoint.rs
    • crates/chat-cli/src/cli/agent/mod.rs
    • crates/chat-cli/src/cli/agent/hook.rs
    • crates/chat-cli/src/mcp_client/client.rs
    • crates/chat-cli/src/database/mod.rs
    • crates/chat-cli/src/auth/mod.rs, auth/builder_id.rs
    • crates/chat-cli/src/api_client/opt_out.rs, api_client/model.rs
    • crates/chat-cli/src/telemetry/mod.rs, telemetry/core.rs
    • crates/chat-cli/src/logging.rs
    • crates/agent/src/agent/mod.rs
    • crates/agent/src/agent/agent_loop/mod.rs, agent_loop/protocol.rs
    • crates/agent/src/agent/permissions.rs
    • crates/agent/src/agent/agent_config/definitions.rs
    • crates/agent/src/agent/tools/*.rs
    • crates/agent/src/agent/mcp/{mod,actor,service,types}.rs
    • docs/hooks.md, docs/built-in-tools.md, docs/default-agent-behavior.md, docs/experiments.md, docs/knowledge-management.md
    • schemas/agent-v1.json
    • terminal-bench-test/main.py
    • （SWE-bench 交叉验证）SWE-bench/experiments evaluation/verified/20240721_amazon-q-developer-agent-20240719-dev/{metadata.yaml,README.md}、 evaluation/verified/20250405_amazon-q-developer-agent-20250405-dev/{metadata.yaml,README.md}

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/amazon-q-developer/ 下：

  • NOTES.md —— 完整调研笔记（含逐维度发现、文件路径、行号、gaps 清单）
  • blog-2024-06-reimagining.md —— AWS ML Blog 原文存档
  • blog-2024-09-reinventing-agent.md —— AWS DevOps Blog 原文存档（任务种子链接）
  • code-excerpts/ —— 关键源文件/文档摘录，包括：
    • q-cli-README.md（仓库根 README，含 Kiro 迁移声明）
    • agent-v1-schema.json
    • docs-hooks.md、docs-built-in-tools.md、docs-default-agent-behavior.md、 docs-experiments.md、docs-knowledge-management.md、docs-tangent-mode.md、 docs-introspect-tool.md、docs-todo-lists.md、docs-agent-format.md
    • terminal-bench-agent.py
    • new-agent-crate_agent_loop_mod.rs、new-agent-crate_agent_loop_protocol.rs、 new-agent-crate_permissions.rs
    • chat-cli_agent_hook.rs
    • chat-cli_tools_delegate.rs
    • chat-cli_tools_execute_mod.rs
    • chat-cli_api_client_opt_out.rs
    • chat-cli_mod_ChatState-and-next.rs（mod.rs 820-1320 行摘录）
    • chat-cli_mod_tool_use_execute-excerpt.rs（mod.rs 2360-2520 行摘录）

已知 gap（如实标注，未填补）：IDE /dev agent（textcode 框架）内部实现全程 无公开源码；RTS 后端具体基础模型未披露；SWE-bench trajectory 实际内容不可访问 （私有 S3、无公开列表）；session 数据是否/如何具体流入 RLHF/微调管线无源码或博客 级证据，仅 opt-out header 证明”有资格被使用”而非机制本身；未发现分布式 追踪/span 格式的可观测性。

关系图谱

反向链接