Coding Agent 设计工作台
围绕九个系统维度输出架构决定、故障路径、验证方式和结课成果
本页解决的问题
先给结论「Coding Agent 设计工作台」要解决的关键问题是什么？
围绕九个系统维度输出架构决定、故障路径、验证方式和结课成果
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
Coding Agent 设计工作台
结课任务从功能清单升级为可运行的系统设计。你要为九个维度作出明确决定，每个决定都要附合约、故障路径、验证方式和可提交成果。
课程目标
完成系统边界
定义入口、状态所有权、模型循环与外部扩展的责任边界。
补齐失败设计
为工具、安全、持久化、恢复和状态通知画出失败路径。
产出可评审成果
提交 ADR、合约、威胁模型、测试与最小演示，不停留在概念图。
一张图看完整 Agent 系统
结课项目简报
为一个真实团队设计「仓库级 Coding Agent」。它至少能读取代码、提出计划、修改文件、执行验证并恢复中断会话。你可以实现最小 PoC，架构文档必须覆盖全部九维。
- 默认最小权限
- 每个外部动作可追踪
- 崩溃后可解释恢复
- 敏感数据有明确落点
- 扩展代码有信任边界
九维决策卡
运行入口
谁启动 Agent，交互、CI 与 IDE 是否共享同一核心？
源码锚点：pager-bin composition root、shell headless/stdio、ACP gateway。
状态 / 并发
谁拥有会话状态，模型流与工具任务如何取消、排队和回传？
源码锚点：SessionActor、LocalSet、后台 summary/persistence actor。
模型流
提示词、流式输出、工具调用、重试、停止与模型切换如何闭环？
源码锚点：run_loop、turn、tool_dispatch、model_switch、two_pass。
工具合约
输入 Schema、返回值、错误、超时、幂等性和权限类别如何标准化？
源码锚点：ToolKind、Tool Bridge、server__tool、capability filter。
上下文 / 记忆
短期上下文何时压缩，长期记忆写什么、何时检索、如何删除？
源码锚点：compaction segments、two-pass、memory FTS/embedding/MMR/Dream。
安全
权限、沙箱、Hook、网络和插件信任分别承担哪一层保证？
源码锚点：capability、sandbox、Hooks fail-open、plugin-root trust。
持久化 / 恢复
消息、工具结果、文件 checkpoint 与外部连接状态如何持久化和重放？
源码锚点：session persistence、chat persistence、rewind、MCP restart。
可观测 / 隐私
哪些事件进入日志和指标，哪些内容必须脱敏、采样或禁止离开本机？
源码锚点：file-utils events、telemetry enums、MCP status payload。
扩展生态
MCP、Plugin 与 Hook 的发现、版本、启用、信任和卸载如何治理？
源码锚点：marketplace index、manifest、install registry、trust store。
真实源码证据导航
xai-grok-shell/src/session/acp_session.rs
xai-grok-workspace/src/capability.rs
xai-grok-memory/src/
xai-grok-hooks/src/dispatcher.rs
mcp_dispatcher.rs · mcp_restart.rs
xai-grok-agent/src/plugins/
设计决定要能回到一个真实分支
// 插件根目录无法 canonicalize 时，不授予信任
match dunce::canonicalize(plugin_root) {
Ok(canonical) => self.trusted.contains(&canonical),
Err(_) => false,
}你的方案也要写清失败默认值。无法读取策略、无法解析工具结果、无法恢复 checkpoint 时，系统分别应当停止、降级或请求用户。
crates/codegen/xai-grok-agent/src/plugins/trust.rs100 分评审量表
否决项：提交物未说明敏感数据落点；高风险工具缺少权限路径；崩溃后声称可恢复但没有测试；引用源码时无法给出文件路径。
课堂练习：90 分钟设计冲刺
最终提交包
可评审设计档案
- 15 分钟：定义用户、仓库、可执行权限和成功标准。
- 20 分钟：完成核心视觉与九维决策卡，标出所有状态所有者。
- 20 分钟：实现一个工具合约与一条模型到工具的最小调用链。
- 15 分钟：注入超时、权限拒绝和进程崩溃，记录恢复结果。
- 10 分钟：完成数据流、脱敏与插件信任检查。
- 10 分钟：用评审量表自评，提交 3 条 ADR、测试记录和 5 分钟演示脚本。
Coding Agent 的完成度体现在边界与故障路径。九维工作台帮助你把模型能力转成可运行、可恢复、可审计、可扩展的工程系统。
源码快照说明：本页以本地 grok-build-main 作为设计案例库，路径锚点来自真实源码。工作台中的交付格式属于课程设计，不声称是 Grok Build 的官方架构模板。学员方案可以采用其他技术栈，但每项决策都要提供同等级证据。
「Coding Agent 设计工作台」为什么能找到相关内容
「结课任务从功能清单升级为可运行的系统设计。你要为九个维度作出明确决定，每个决定都要附合约、故障路径、验证方式和可提交成果」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「为一个真实团队设计「仓库级 Coding Agent」。它至少能读取代码、提出计划、修改文件、执行验证并恢复中断会话。你可以实现最小 PoC，架构文档必须覆盖全部九维」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
- 15 分钟：定义用户、仓库、可执行权限和成功标准
- 20 分钟：完成核心视觉与九维决策卡，标出所有状态所有者
- 20 分钟：实现一个工具合约与一条模型到工具的最小调用链
先区分找得到和找得准
把「源码快照说明： 本页以本地 grok-build-main 作为设计案例库，路径锚点来自真实源码。工作台中的交付格式属于课程设计，不声称是 Grok Build 的官方架构模板。学员方案可以采用其他技术栈，但每项决策都要提供同等级证据」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「Coding Agent 设计工作台」走到「完成系统边界」
「Coding Agent 设计工作台」先把问题落在「结课任务从功能清单升级为可运行的系统设计。你要为九个维度作出明确决定，每个决定都要附合约、故障路径、验证方式和可提交成果」上；到了「完成系统边界」，讨论继续推进到「定义入口、状态所有权、模型循环与外部扩展的责任边界」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「Coding Agent 设计工作台」：结课任务从功能清单升级为可运行的系统设计。你要为九个维度作出明确决定，每个决定都要附合约、故障路径、验证方式和可提交成果
- 「完成系统边界」：定义入口、状态所有权、模型循环与外部扩展的责任边界
- 「最后的要点」：10 分钟：完成数据流、脱敏与插件信任检查
最后的「最后的要点」把讨论落到「10 分钟：完成数据流、脱敏与插件信任检查」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。