企业官网建设流程全解析

• 人工智能
• AI Agent
• 代码智能体
• 自主智能体
• MCP Clients
• CLI

导读：本文以 docs/release-v5.0.1-current-branch-change-report.md 为骨架，全面解读 AtomCode 在 release/v5.0.1 分支上完成的"引擎 driver 调用链 legacy 接口面退役"这一核心迁移：CLI、TUI、daemon、background、ACP 与 clix 如何统一到 kernel 原生命令、事件与CodingRuntime生命周期边界，以及request_user_input新交互如何在不恢复旧协议的前提下接入 native runtime。读完本文，你将掌握该分支的提交结构、新旧调用链差异、运行时不变量、测试证据体系与已知问题，并能在实际迁移中复用其"四态退役"判定口径。

1. 报告背景与结论：0 behind / 5 ahead

该报告生成于 2026-07-18，对比对象为release/v5.0.1_1@cfe4209c（当前分支）与origin/release/v5.0.1@9fcc92d9（最新远端），merge-base 为9fcc92d9。核心结论如下：

• 当前分支完整包含最新release/v5.0.1，提交关系为0 behind / 5 ahead；
• 基线采集时工作区干净，报告生成后仅新增本文档；
• 本分支的核心修改是彻底退役core/bridge旧引擎调用链，将 CLI、TUI、daemon、background、ACP 和 clix 统一到 kernel 原生命令、事件及CodingRuntime生命周期边界；
• 最新分支新增的request_user_input已通过 nativeCodingRuntimeEvent::Request / DriverCommand::Respond接入，没有恢复已删除的 bridge 或 core legacy driver 协议。

报告采用项目的"四态口径"给出迁移判定：

因此引擎 driver 调用链达到"legacy 接口面已退役"状态。但报告同时谨慎指出：最终树尚未完成所有受影响 crate 的完整测试和真实 provider 跨入口 smoke，当前测试证据"足以支持合并后的编译与定向行为判断，不足以替代发布前全量验证"。

2. 对比基线与规模

2.1 基线数据

从净改动规模（删除行数远超新增行数）可以看出，这是一次典型的"减法式重构"：删除约 2.2 万行 legacy 代码，新增约 1.3 万行 native 实现，整体代码面明显收缩。

2.2 当前独有提交

报告明确指出：真正的本地功能变更集中在前两个提交；后三个提交负责持续同步远端并解决新功能与 runtime 退役之间的协议冲突。

3. Runtime 与协议退役：从 bridge 到 CodingRuntime

3.1 旧链路 vs 新链路

报告给出的旧调用链（legacy bridge）：

driver -> core AgentCommand -> atomcode-bridge / daemon adapter -> kernel -> core AgentEvent -> driver

新调用链（native runtime）：

CLI / TUI / daemon / background / ACP / clix -> CodingRuntimeHandle / DriverCommand -> CodingRuntime -> kernel AgentCommand / AgentEvent -> CodingRuntimeEvent -> driver-local projection

从源码结构看，新链路的核心载体是 crates/atomcode-coding/src/runtime.rs：

• CodingRuntime（约 runtime.rs#L1407）持有handle、events、task和session四个字段，作为唯一 runtime owner 对外暴露；
• CodingRuntimeHandle（runtime.rs#L1689）是驱动侧的命令入口；
• CodingRuntimeEvent（runtime.rs#L93）是#[non_exhaustive]的原生事件枚举，涵盖Agent、Team、VisionPreprocessSuccess/Failed、SteerAcknowledged、CompactionStarted/Finished、RuntimeStopped、Request、TurnFinished、PolicyInterventionResolved等，全部不依赖 legacyatomcode-coredriver 协议；
• DriverCommand（runtime.rs#L818）是原生命令枚举，包含Submit、Respond、Cancel、PauseGoal、Compact、SetMode、ReloadProvider、UndoToPrompt、Rewind、StartGoal/StopGoal/StartLoop等，被报告称为"core AgentCommand channel 在异步 runtime 启动期的原生替代"。

3.2 实际删除项清单

报告明确列出的删除项包括：

• 整个atomcode-bridgecrate、Cargo 依赖和 lockfile 记录；
• coreagentdriver 协议及 goal、loop、compression、parallel-edit legacy 实现；
• core v1TurnRunner、permission、loop guard、tool args、datalog、log 旧执行链；
• CLI、TUI、daemon、background 对 bridge/core legacy command/event 的发送和消费；
• daemon 重复 kernel driver、双引擎入口及 mixed legacy/native event；
• TUI legacy/native 双 endpoint。

静态搜索确认生产代码中不再存在以下符号：

atomcode_bridge spawn_bridged_runtime_with_control BridgedRuntime BridgeConfig atomcode_core::agent::AgentClient atomcode_core::agent::AgentCommand atomcode_core::agent::AgentEvent ATOMCODE_DAEMON_ENGINE DaemonRuntimeEvent::Legacy DaemonRuntimeEvent::Native

3.3 生命周期统一

CodingRuntime成为唯一 runtime owner，统一管理：

• provider 构建、reload 和 reassemble；
• fresh、resume、restore、undo、change directory；
• session id、working directory、snapshot 和 generation；
• submit、steer、cancel、approval 和 shutdown；
• compact exactly-once terminal；
• goal/self-paced loop 的互斥、held turn、wakeup 和 terminal；
• background、daemon、TUI 和 headless 的统一事件来源。

报告同时列出主要不变量（invariants）：

• 一个CodingParts不产生两个 live agent；
• lifecycle 操作由 actor 串行化；
• provider/session 切换失败不得静默回退 fresh session；
• pending request 在 cancel、reload、session switch 和 shutdown 时 fail-closed；
• stale generation 事件不得进入 replacement runtime；
• snapshot、provider、working directory、approval grants 和 gateway affinity 不因 reassemble 丢失。

源码中"droppingeventscauses a fail-closed shutdown"（runtime.rs#L1406 附近注释）与"authorised state 变更前的 fail-closed 顺序"（runtime.rs#L1306 附近）直接印证了 fail-closed 不变量；RuntimeRequest（runtime.rs#L627）携带id、kind、payload和可选snapshot，正是 request id 关联与 fail-close 的实现载体。

4. Daemon 与 driver 的 native 化

Daemon 侧改为使用统一CodingRuntime：

• 删除重复的KernelDriver生命周期实现；
• 增加 native runtime host；
• legacy_convert.rs仅用于历史 session/snapshot 数据转换，不能投递旧 engine command；
• HTTP、SSE、WebSocket 只负责 native runtime event 的传输映射；
• /chat文本模型图片输入复用 VL 预处理策略：原图继续用于持久化和缩略图，kernel 输入使用 VL 描述。

源码佐证位于 crates/atomcode-daemon/src/kernel_runtime.rs：该文件开篇即注明"Daemon entry points for the unified nativeatomcode_coding::CodingRuntime"，内部调用CodingRuntime::start_with_session_lease/CodingRuntime::start_with_bootstrap，并在事件循环中匹配CodingRuntimeEvent::Agent(...)等原生事件（见 kernel_runtime.rs#L235 附近）；legacy_convert的converge_session仅被用于会话数据收敛（kernel_runtime.rs#L103、kernel_runtime.rs#L129）。

另一个值得注意的行为约定：CLI/headless、clix 和 daemon 对无法交互处理的非 approval request 统一返回Null，避免工具回合永久挂起。这与request_user_input.rs中null_result()返回 "Interactive questions are not supported in this environment." 的实现完全一致。

5. request_user_input 合并适配：保留产品行为，迁移协议接入点

最新release/v5.0.1新增的request_user_input是本分支合入的最重要新功能。报告的关键决策是：保留其产品行为，但将协议接入点迁到 native runtime，且没有恢复远端曾新增的 coreAgentEvent::Request / AgentCommand::Respondbridge passthrough。

5.1 接入点设计

• kernel 增加Requester和ToolContext.request；
• capability 注册request_user_input，默认关闭，由ATOMCODE_REQUEST_USER_INPUT控制；
• 工具名始终进入 coding allowlist，实际 mount 仍以环境开关和注册结果为准；
• persona 提示与工具开关保持一致；
• runtime 关联 request id，并在 cancel/reload/shutdown 时 fail-closed；
• TUI 支持 single、multiple、text、自定义文本、Esc、Ctrl+C 和 bypass 自动跳过；
• single 模式在选项行按 Enter 立即提交，不显示单独 Submit 行；
• multiple 模式保留 Submit 行，并可附加自由文本；
• CLI/headless、clix 和 daemon 对非交互 request 返回Null。

5.2 源码级实现

Requester定义在 crates/atomcode-kernel/src/request.rs：它是一个"thin, cloneable handle exposing ONLY the request round-trip"，通过RequestFn（Arc<dyn Fn(String, Value) -> BoxFuture<'static, Value>）抽象驱动侧应答，且支持RequesterInner::Kernel(RequestCtx)与RequesterInner::Host(RequestFn)两种实现——工具无法区分差异，request_user_input无论由谁运行都以同样的方式发问。

request_user_input工具本身位于 crates/atomcode-capabilities/src/tools/request_user_input.rs：

• REQUEST_USER_INPUT_KIND = "request_user_input"是通用 request/respond round-trip 的 kind 字符串；
• UserInputMode（single / multiple / text）、UserInputRequest（question、header、mode、options、custom）、UserInputResponse（declined、selected、text、images）构成完整协议类型，供各 driver 导入；
• MAX_QUESTIONS = 4限制单次批量提问数量；
• parse_args/parse_batch负责参数解析，并内置弱模型字段修复逻辑：fill_default_mode在模型漏传mode时根据options是否为空推断 single/text；fill_default_header在 header 缺失时从 question 首行派生短标签，HEADER_MAX_CHARS = 24且按字符（非字节）截断，保证中文问题不会被拦腰截断；
• 选择类模式（single/multiple）要求非空options数组，否则报错；
• legacy 字段custom被统一归一化为true，确保用户永远保留自由文本逃生通道；
• null_result()处理无 driver 可展示问题的场景。

5.3 测试证据

报告 6.1 节记录了cargo test -p atomcode-capabilities -p atomcode-kernel -p atomcode-coding -p atomcode-tuix request_user_input通过（capability 10 项、persona 1 项）；cargo test -p atomcode-tuix user_input19/19 通过（覆盖 single/multiple/text、自定义文本、Submit、Esc、Ctrl+C、bypass、render）。

工具自身的单测覆盖了选择无 options 报错、缺 mode 推断 single/text、缺 header 派生、批量逐题修复、custom:false归一化为true、选中项与自由文本同时回传、附加图片转发等关键行为（见 request_user_input.rs#L576 起的测试模块）。

5.4 环境开关（默认开启，可关闭）

环境变量ATOMCODE_REQUEST_USER_INPUT控制工具的挂载与 persona 提示，默认开启，可通过0、false、off或空值显式关闭。判定逻辑有两处刻意保持同步的实现：

• 工具注册侧：crates/atomcode-capabilities/src/tools/mod.rs中request_user_input_on块（mod.rs#L249-L272），默认 ON，0/false/off/empty时跳过注册；
• 权威解析侧：crates/atomcode-config/src/config/mod.rs::request_user_input_enabled_from_env（config/mod.rs#L2006-L2025），被atomcode-coding的 persona 门控request_user_input_switch_enabled（crates/atomcode-coding/src/persona.rs）调用。

注意源码注释强调：atomcode-config不是atomcode-capabilities在toolsfeature 下的依赖，因此两处逻辑是"INTENTIONAL DUPLICATION"，修改时必须同步镜像。

此外，工具名request_user_input无条件出现在coding_tool_names()允许清单中（crates/atomcode-capabilities/src/tools/mod.rs#L147），实际 mount 时由注册结果决定——"registered != mounted"，只有注册成功且名字在 allowlist 中，工具才会出现在模型 API 的tools数组里。

5.5 与 kernel Request/Respond round-trip 的对接

DriverCommand::Respond { id, value }（runtime.rs#L820）是驱动侧应答入口，CodingRuntimeControl::Respond继而将应答投递给 kernel 的AgentCommand::Respond { id, value }（见 runtime.rs#L4883 附近）。测试中可见CodingRuntimeEvent::Request(RuntimeRequest { id: 7, .. })与AgentCommand::Respond { id: 7, value }的完整 round-trip 断言（runtime.rs#L16829、runtime.rs#L16844），印证了 request id 关联与应答投递路径。

6. AtomGit/GitCode 网关认证下沉

请求签名逻辑从 bridge/core 下沉到atomcode-auth和 capabilities provider：

• 网关识别按 HTTPS scheme 和精确 host 判断；
• OAuth token、user id、timestamp 和随机 nonce 统一参与签名；
• 源码构建暴露 unavailable signer，不伪造签名成功；
• 官方构建通过atomcode-core/codingplan-crypto -> atomcode-auth/codingplan-crypto启用闭源 overlay；
• 81985e9c恢复了迁移中遗漏的 feature 声明和依赖透传。

源码实现位于 crates/atomcode-auth/src/gateway_crypto.rs：RequestSignertrait 定义sign与algorithm_version；SignInput携带 method、path、body、oauth_token、user_id、timestamp_unix 与 16 字节 nonce；未启用codingplan-cryptofeature 时使用UnavailableSigner（algorithm_version() == 0，sign 恒返回SignError::Unavailable）；启用后RealSigner仍先校验algorithm_version() != 0，避免"feature 选择本身不能证明官方 overlay 存在"（"Refuse before entering the public placeholder's panic-only sign_v1"），随后调用atomcode_codingplan_crypto::sign_v1生成签名头。这正是报告所述"源码构建暴露 unavailable signer，不伪造签名成功"的实现依据。

7. TUI 与 VSCode 侧改动

7.1 TUI

• 使用 runtime control 和 TUI-localUiEvent；
• 新增结构化用户输入面板；
• /usage按显示宽度处理 CJK 对齐；
• foreground/background、approval、mode、session replay 和 undo 继续使用统一 runtime。

7.2 VSCode

• chat font family 和输入框字体行为调整；
• provider queue 在无 focused panel 时仍按 session 正确排队和出队；
• approval mode pending 状态不会被 initial state 覆盖；
• session 展示继续按当前 workspace/project 过滤。

8. 影响范围评估

报告给出的影响面矩阵：

9. 已知问题与审计结论

9.1 文档静态验收项不完全一致

迁移设计文档把KernelRuntimeAdapter列入最终静态零命中项，但当前atomcode-coding/src/runtime.rs仍保留同名内部类型（见 runtime.rs#L3678）。该类型服务于 kernel agent 管理和 compaction（提供suspend_compaction、resume_compaction、stop_agent、replace_agent、shutdown等管理方法），不依赖 bridge，也不能投递 core legacy command，因此不构成 legacy fallback；但文档的字面验收标准与代码不一致，应修正文档或重命名该内部类型。

9.2 README 架构描述陈旧

中英文 README 仍描述 coreAgentLoop通过AgentCommand / AgentEvent与 TUI 通信，与当前CodingRuntime架构不一致。这不影响运行时行为，但会误导后续维护者。

9.3 删除旧测试后的覆盖迁移

bridge stream timeout、core turn runner、hook integration 等旧链路测试随实现删除是合理的；对应行为必须由 kernel、capabilities、CodingRuntime 和各 driver parity 测试继续覆盖。不能只依据删除代码量判断退役完成。

10. 测试依据与未完成验证

10.1 最终合并树cfe4209c的测试证据

编译期间存在一个既有 warning：atomcode-kernel/tests/liveness.rs的SilentStreamProviderunused import。该 warning 不影响验证结果，但应在后续维护中清理。

10.2 迁移提交父树的补充测试证据

在合入最新版request_user_input前，曾从干净HEAD快照执行更广范围测试：

报告强调：上述补充结果证明迁移主体已有较广测试基础，但它们不是最终cfe4209c全量测试的替代品。

10.3 未完成验证清单

• 最终合并树尚未运行所有受影响 crate 的完整cargo test --all-targets；
• 尚未完成真实 provider 的 CLI、TUI、daemon 跨入口 smoke；
• 尚未在真实交互中覆盖 approval、cancel、resume、provider reload、图片 VL 预处理和request_user_input全模式组合；
• 未执行发布构建中的闭源codingplan-cryptooverlay 验证。

11. 迁移状态与唯一下一步

11.1 迁移状态总表

11.2 唯一下一步

在磁盘空间充足的环境中，对最终cfe4209c运行受影响 crate 的完整 all-target 测试，然后使用真实 provider 做一次 CLI、TUI、daemon 跨入口 smoke，覆盖 turn、approval、cancel、resume、provider reload、图片输入和request_user_input；只有这一步完成后，才能把当前结论从"编译与定向行为判断"提升为发布级验证完成。

12. 可复用的工程方法论

从这份报告可以提炼出适用于大型 Rust 工作区"引擎退役迁移"的实践要点：

1. 四态退役口径：以"新逻辑已实现 / driver 已切换 / 无 legacy fallback / legacy 接口面已删除"四个状态判定迁移进度，避免只凭代码删除量下结论；
2. 静态搜索符号清单：用一组精确符号（如BridgedRuntime、AgentClient、DaemonRuntimeEvent::Legacy）做全仓零命中验证，作为"接口面退役"的可审计证据；
3. 双份 env 开关逻辑显式同步：ATOMCODE_REQUEST_USER_INPUT在 capabilities 注册侧与 config 解析侧刻意复制实现，并以注释声明"INTENTIONAL DUPLICATION，改动必须镜像"，防止依赖方向错误的隐式耦合；
4. fail-closed 优先级：pending request 在 cancel/reload/session switch/shutdown 时一律 fail-closed，杜绝越权、误拒绝与回合挂起；
5. 区分"实现删除"与"行为覆盖"：旧测试随实现删除合理，但行为必须由新链路测试继续覆盖，报告明确警告"不能只依据删除代码量判断退役完成"；
6. 文档验收标准与代码保持同步：KernelRuntimeAdapter字面验收与实现的偏差被明确记录为待修正项，避免静态验收项沦为无效约束。

• 人工智能
• AI Agent
• 代码智能体
• 自主智能体
• MCP Clients
• CLI