人们谈论智能体时，默认它一直在线：随时查资料、随时调接口、随时把结果同步出去。但在很多真实场景里，网络并不可靠，车间、野外作业、隔离内网、移动途中的弱网环境都可能让智能体长时间离线。离线智能体的设计目标不是把联网版本阉割后硬塞进本地，而是从一开始就按断网可用的方式组织工具、知识和状态。

核心是本地工具注册表。智能体在离线时能调用什么，不能调用什么，必须在本地就能查到，而不是等到调用时才发现某个工具依赖远程服务。每个本地工具应当自带清晰的用途说明、参数要求和失败表现，让智能体在调用前就能判断是否适用。参数校验也要放在本地做：格式、范围、必填项先在本地过一遍，避免把明显错误的参数攒到联网后才暴露。

其次是知识的时效管理。离线智能体依赖的本地知识总有过期的一天，设计时要让每份知识带有来源和时效标记。面对时效敏感的问题，宁可明确告诉用户这份信息来自本地存量、可能已经过时，也不要用旧信息装作最新结论。时效要求高的判断应当推迟到恢复联网后再做，而不是在离线状态下硬给答案。

第三是状态的本地保存与事后同步。离线期间产生的操作记录、中间结果和待办事项都要完整保存在本地，等网络恢复后再按顺序同步。同步时要处理冲突：离线期间改动过的数据，可能已经被其他人或系统改过，直接覆盖会丢数据。常见的做法是按时间与操作类型区分冲突情形，能自动合并的合并，不能自动合并的标记出来请人确认，而不是静默覆盖。

安全边界在离线时同样不能放松。本地工具的权限应当和联网时一致，不能因为离线就放宽限制。涉及敏感操作、对外承诺、高风险变更的步骤，离线时应当暂缓或改为草稿状态，等恢复联网并经过确认后再执行。离线不是法外之地，权限、审计和留痕一套都不能少。

最后是测试方法。离线能力不能只靠上线后偶遇断网来验证，应当在开发阶段就主动模拟断网：切断网络、逐个调用本地工具、检查降级表现、再恢复网络验证同步与冲突处理。只有把断网当作正常工况来测试，智能体在真实断网时才不会手足无措。