# 3.5 本章小结

第三章的目标是建立“本地最小闭环基准线”：在不引入外部渠道变量的前提下，验证主链路可用、可观测、可复验，并为后续的配置调优与扩展落地提供稳定的参照系。

## 3.5.1 关键设计原则沉淀

完成本章后，应形成以下关键结论：

* 基准线优先：先在 Dashboard/WebChat 验证固定用例，再扩展渠道与能力，避免变量叠加导致问题难复现。
* 指令是契约：初始指令（instructions）要写成可检查条款（目标/边界/输出结构），并配合日志回放验证其生效。
* 设备批准是最小防线：本地访问通过设备批准机制实施，理解这个机制是后续渠道级安全策略的基础。
* 诊断看顺序：先 `health`（进程），再 `channels --probe`（渠道），再 `models --check`（模型），最后 `logs`（日志），避免先改提示词掩盖根因。

## 3.5.2 自检清单

建议在进入下一章前自检：

* 是否能验证 3.1 的三个最小用例（健康链路、最小交互、流式输出），并在 `logs --json` 中定位到对应的请求与响应？
* 新设备访问 Dashboard 时的批准流程能否完成闭环？能否解释批准对访问范围的影响？
* 当出现“未回复/未触发”时，能否正确应用四层诊断顺序（进程 → 渠道 → 模型 → 日志）快速定位？

## 3.5.3 下一步规划预告

[第四章](https://yeasy.gitbook.io/openclaw_guide/di-yi-bu-fen-ji-chu-ru-men/04_config_models)进入配置体系与模型接入：把“正常运行”升级为“可控可替换”，并建立可验证的模型选择与故障转移基线。后续章节将依次深化：[第五章](https://yeasy.gitbook.io/openclaw_guide/di-er-bu-fen-jin-jie-shi-yong/05_tools_skills)讨论工具策略与权限治理，[第六章](https://yeasy.gitbook.io/openclaw_guide/di-er-bu-fen-jin-jie-shi-yong/06_context_memory)讨论记忆与会话隔离，[第七章](https://yeasy.gitbook.io/openclaw_guide/di-er-bu-fen-jin-jie-shi-yong/07_multi_agent)讨论多渠道入口治理与多智能体协作。