第二十六章：从教学程序走向可运营系统

26.1 升级应沿风险边界推进

不要一次加入真实模型、任意 Shell、多人协作和远程执行。这样出现问题时，很难区分模型选择、协议翻译、权限与并发。先保持同一验收任务，逐条替换能力，并为每条新边界增加故障实验。

第一阶段可以接入真实模型但只读；第二阶段在明确工作区与执行身份下启用写入；第三阶段增加有句柄的长进程；之后再考虑远程与多用户。阶段不是发布承诺，而是隔离问题的一种工程顺序。

用户设置、项目配置、组织策略和插件建议可能冲突。需要定义优先级、哪些值可由不可信项目覆盖，以及运行途中更新何时生效。把所有配置 merge 成一个对象，却不记录来源，可能让权限变化难以解释。

工具快照与上下文版本帮助说明某一步使用哪份配置。持久事件可以记录重要决策的有效身份，但敏感凭据不应直接写入日志。可记录凭据引用或版本，实际秘密由受控存储解析。

MCP 可以把外部服务器的工具与资源带入代理，但不会自动解决本地授权、远程副作用和结果可信性。工具名称还可能与本地注册冲突，需要命名空间与来源身份。

接入时应核对发现、连接、超时、取消、重连和关闭。服务器在网络断开后可能仍继续工作；本地缺少响应并不等于远端未执行。将这些调用映射为普通工具时，必须保留其更复杂的恢复语义。

会话格式一旦发布，就要考虑旧版本读取、新字段默认值、迁移失败和备份。迁移不能只有一段“尽力 parse”，还应说明何时拒绝未来版本、是否修改原文件、怎样验证后继产物。

DeepSeek 的 generation 模块提供了可继续研究的实际入口。对于小型项目，也可以先采用明确的版本号与不就地改写原则，等有实际需求再增加复杂迁移框架。DeepSeek Harness · generation.ts L253–267

除任务成功率外，记录异常停止率、未知结果数、恢复人工介入量、取消清理时间、附件缺失与策略拒绝。它们分别指出可靠性、恢复、资源和授权层的问题。

事故处理应先保存现场和确认活跃进程，再考虑重试。特别是有外部副作用的任务，不应因为 UI 看不到结果就重新发起。一次有纪律的核查，比一份看似完整但重复执行的成功报告更重要。

发布时给出版本、配置边界、运行命令、任务样本和验证范围。让新使用者能复现最小成功、拒绝和恢复案例。文档说明应与程序行为同步，自动构建还应核对在线版与下载版是否使用相同正文。

本书本身采用这项原则：同一份 Markdown 生成 EPUB 与在线章节，构建时核查源码引用、章节链接与资源，实验独立执行，发布后再检查公开阅读与下载地址。书籍制作也是一种需要证据的工程交付。