⚙️ 第六篇：部署与生产化
第13章 边界与进阶路线：从 Demo 到产品
诚实地面对不足，才是从 Demo 走向产品的起点
13.1 本章导读
走到这里，你已经掌握了 deepseek-harness-java 的主线架构、核心机制与部署路径。本章不追求“完美收尾”，而是做两件事：诚实地盘点系统当前的边界与隐患（很多教程回避这个，但它对一个要上线的系统至关重要），以及给你一条继续进阶的路线。
13.2 已知边界清单
13.2.1 安全与治理
| 问题 | 现状 | 影响 |
|---|---|---|
| shell_execute 零沙箱 | LocalShellExecutor 直接 /bin/sh -c，无命令白名单 | 仅靠提交期审批兜底，对话链路可绕过 |
| 运行期审批 gate 未启用 | AgentFactory 默认 approvalBroker=null | 对话链路高风险工具不被拦截 |
| 鉴权过简 | API Key 拦截器 + 空 key 全放行 + actuator 公开 | 不适合直接暴露公网 |
13.2.2 稳定性与性能
| 问题 | 现状 | 影响 |
|---|---|---|
| ScheduleService 形同虚设 | drive() 无 @Scheduled/Quartz 调用方，仓储 InMemory | 定时任务不触发，重启即丢 |
| 无界线程池 | ReactLoopAgent.kick() 与 JobRegistryService 用 newCachedThreadPool | 高并发下线程暴涨风险 |
| 阻塞请求线程 | AgentCollectNode 等用 .join() | 占用 Tomcat 工作线程 |
| 长会话 O(n²) | deriveMessages 全量重建；token 用 length/4 粗估 | 长会话性能衰减 |
13.2.3 功能完整性
| 问题 | 现状 |
|---|---|
| E2B 沙箱 | 只有 Stub 实现，未接真实远程沙箱 |
| CODEX/CORDIS 插件 | 包型能识别但 runnable=false，是死路径 |
| MCP 与插件 Bridge | 互不打通 |
| 工作流 SSE | 只推终态事件，无增量 |
| 分布式 | 单实例设计，无集群协调 |
💡 为什么要把这些写出来
因为这些问题每一个都是绝佳的练手入口。它们边界清晰（都有明确的现状描述）、价值明确（都是真实痛点）、难度分层（从"加个 @Scheduled"到"设计分布式协调"都有）。想真正吃透这个项目，最好的方式就是挑一个动手修。
13.3 进阶路线：三个方向
🔧 方向一：补齐短板
从 13.2 的清单里挑问题修。推荐起点：给 ScheduleService 加 @Scheduled 驱动（半天）、把 newCachedThreadPool 改有界（半天）、启用运行期审批 gate（一天）。每个都是独立 PR。
🚀 方向二：扩展能力
用第9、10章的技能写自己的插件或接 MCP Server——接入你公司的内部系统、接数据库、接监控平台。这是把项目"用起来"的最短路径。
🏗️ 方向三：架构演进
挑战大题：Agent 内存状态外置（Redis/DB）实现多实例、任务分布式锁、会话亲和性路由、E2B 真实沙箱接入。这些是分布式 Agent 系统的核心难题。
13.4 主线回顾
回看第 1-13 章的主线：
| 如果你只记住五句话 |
|---|
| 1. Harness 是 LLM 之外的工程外壳——模型是黑盒，但模型触达系统的每条路径必须是白盒。 |
| 2. 六边形架构让 Domain 居中定义端口，Infrastructure 实现端口——换模型、换数据库不动核心。 |
| 3. SessionLog 事件溯源是真相之源——回放、取消、审计都建立在"事件只增不改"上。 |
| 4. 所有工具（内置/插件/MCP）穿过同一个 ToolCallExecutor——统一入口是治理的前提。 |
| 5. 能力越大越需要缰绳——权限矩阵、审批、沙箱是 Agent 系统上线前不可省略的部分。 |
13.5 小结与工程全景预告
Agent 系统的难点从来不在"让模型说句话"，而在"让模型安全、可控、可审计地动手做事"。这个项目把一个生产级 Harness 该考虑的绝大部分问题——架构、事件、工具、插件、治理、部署——都摆在了台面上，连同它的不足一起。读懂它，修好它，扩展它，你就拥有了一个真正属于自己的 Agent 运行时。
教程源码与项目同在：gitcode.net/KnowledgePlanet/deepseek-harness-java
欢迎 Star、Issue、PR —— 特别是，欢迎你从 13.2 的清单里挑一个，把它修掉。