最近在帮团队搭建内部知识问答和任务自动处理系统时，折腾了一套基于 Docker 的 DeepSeek Harness 部署方案。所谓 Harness，说白了就是给 DeepSeek 模型套上一层“编排缰绳”，让它可以按你的指令拆解任务、调用工具、多轮推理，最终变成一个真正干活的 AI Agent。部署完后，整个局域网内的同事都能通过浏览器访问这个平台，数据全部留在内网，不需要把任何业务资料传到公网。这套方案实测下来很稳，这次把从设计思路到最终落地的完整过程记录下来。
这个项目适合三类人：一是想在局域网内部署 AI Agent 平台、但对 Kubernetes 这类重型方案望而却步的团队；二是想用国产开源大模型做应用开发、又不想碰复杂训练流程的开发者；三是需要快速验证 Agent 工作流、想把模型能力嵌入内部工具链的产品和技术负责人。整体方案只有一个前提——一台能跑 Docker 的 Linux 服务器，最好有 NVIDIA 显卡，如果没有，也可以用 API 方式接入模型服务。
1. 项目整体设计与思路拆解
1.1 为什么要用 Docker 来承载 AI Agent 平台
如果直接在主机的 Python 环境里搭建 Agent 平台，最常见的问题就是依赖冲突。Agent 平台本身需要一整套 Python 依赖，模型推理服务可能有自己的 CUDA 版本要求，前端静态文件服务又可能需要独立的 Node 环境，三套环境挤在一台机器上，光是解决版本兼容就能耗掉半天时间。Docker 的容器化恰好把这个问题拆解干净：每个服务跑在独立容器里，环境互相隔离，通过编排工具统一管理。
更重要的是，AI Agent 平台通常不是单一进程，而是由 Web 前端、API 后端、任务队列、模型推理服务等多个组件组成。用 Docker Compose 将整个项目定义为一个服务集群，可以做到一键拉起、一键停止、统一日志查看，这在后续升级和维护时的价值非常大。举个实际场景：我在调试阶段需要频繁替换后端代码，只需要重新构建后端的镜像再重启对应容器，其他服务完全不受影响。这在传统部署方式下很难做到。
局域网的部署场景还有一个特点：网络环境可控，不需要复杂的公网网关、HTTPS 证书、负载均衡。Docker 的端口映射加局域网 IP 直接访问，是最简单可靠的方案。这正是选择 Docker 而不是 Kubernetes 的原因——在单机局域网环境下引入 K8s 属于典型的过度设计，反而增加了维护成本。
1.2 DeepSeek Harness 的核心价值
DeepSeek Harness 这个名字听起来有点抽象，拆开看就清楚了。DeepSeek 是模型基座，负责理解和生成；Harness 是编排层，负责控制模型如何工作。原始模型只是一个对话接口，输入提示词输出回答，但 Agent 平台需要的是：解析用户意图、拆解任务步骤、选择调用哪些工具、根据工具返回结果再推理下一步行动。这一整套逻辑如果全写在业务代码里，会导致业务代码与模型逻辑强耦合，换个模型就要重写一半代码。
Harness 的存在就是把这层编排逻辑独立出来，通过配置文件和工作流定义来驱动模型。我使用的方案中，Harness 主要提供四个能力：模型接入抽象层、工具注册与管理、任务规划与执行引擎、可视化交互界面。模型接入抽象层解决的是“怎么连模型”的问题，既支持连接本地推理服务，也支持连接 API 接口，切换时只需要改配置。工具注册机制允许把任意的 Python 函数或外部命令封装成 Agent 可以调用的“工具”，比如查数据库、发 HTTP 请求、操作文件系统等。
实际使用中，这套组合的效果是：原本需要人工在线填表、查记录、生成摘要的重复性工作，现在通过自然语言描述需求，Agent 可以自动完成。比如让 Agent“把服务器上所有大于 1GB 的日志文件按大小排序，生成一个 Markdown 表格，然后放到指定目录”，它能够拆解为三个步骤——遍历目录、筛选排序、写文件——并在执行过程中反馈进度。这种能力在团队内部使用场景中非常实用。
2. 核心架构与设计思路拆解
2.1 整体技术栈与分层架构
这套部署方案的技术栈非常标准，主要由四个层次构成。最底层是 Docker 与 Docker Compose，负责整个运行环境的承载和编排；往上是模型推理层，使用本地推理服务框架加载量化版模型，通过标准 OpenAI 兼容接口对外提供模型能力；再往上是 Harness 核心引擎层，承载 Agent 的规划、执行、工具调用与对话管理；最上层是 Web UI 层，提供浏览器交互入口，让局域网用户无需安装任何客户端。
每一层之间通过标准的 HTTP 接口通信，这是整个架构的关键设计。模型层暴露的是兼容 OpenAI 格式的/v1/chat/completions接口，Harness 引擎层则实现为后端 API 服务，UI 层调用后端 API。这种分层的好处在于每一层都可以独立替换。比如初步跑通后，将本地推理服务换成一个云端模型 API，只需要修改 Harness 的环境变量，不用动任何代码。
如果硬件条件充裕（比如显存超过 24GB），也可以把量化级别调高或者使用更大参数规模的模型，推理层对上层完全透明。我在使用中用一个 16GB 显存的显卡，加载量化后的模型，运行长上下文任务会有明显延迟，所以显存调度策略需要根据硬件配置动态调整。
2.2 为什么选择“模型+编排框架”而不是一体化应用
做这个项目前，我也对比过市面上的一体化 Agent 应用，它们通常把模型、知识库、工作流整合在一个包内，部署确实简单，但问题也随之而来：定制能力弱。一体化应用封装了太多内部逻辑，想修改 Agent 的行为模式、加入内部专用工具，要么等官方更新，要么把整个应用拆开改，这个复杂度跟直接用编排框架差不多，却丧失了对底层的控制。
选择“模型+编排框架”的组合，更像是搭积木。模型是大脑，编排框架是神经系统，工具是手脚。这种组合让每一步都可控——哪一步出的问题，直接定位到对应模块。举个例子，有一次 Agent 在任务规划时反复调用了某个不存在的工具，如果是黑箱的一体化应用，这个排查会比较困难；而在 Harness 架构下，我直接查看后台的运行日志，定位到工具注册表里少了一个声明，改配置后立刻恢复。这种可观测性和灵活性，是内部部署场景中最有价值的特性。
从团队协作角度考虑，模型与编排解耦还有一个好处：不同角色关注的层面不同。运维关心容器的运行状态和资源占用，开发者关心工具函数和业务逻辑，用户只关心界面交互。分层架构下，这些角色可以并行工作，互不阻塞。
3. 关键能力与配置要点解析
3.1 模型接入：本地推理还是 API 服务
这一步是整套方案中最核心的配置决策。模型接入有两种模式，选择哪个直接决定你的硬件需求和部署形态。
本地推理模式是将模型部署在局域网内部的推理服务中，通过 GPU 进行计算。这种模式的核心优势是数据完全内网流转，适合处理涉及内部数据或敏感信息的任务。缺点是对硬件有一定要求。以我使用的 8B 量化模型为例，模型权重大约需要 6-8GB 显存，加上推理过程中的 KV Cache、中间激活值，实际建议显存不少于 12GB，如果想要更高的上下文长度，16GB 会更稳妥。粗略估算显存需求的公式是：显存需求 ≈ 模型权重内存 + 上下文长度 × 每个 Token 的显存开销，同样是 8B 模型，4K 上下文和 32K 上下文的显存需求差距非常明显。
API 模式则是通过 HTTP 请求调用外部模型服务，本地只运行 Harness 引擎。这种模式适合硬件配置不足的团队，速度一般更快，但需要将对话数据发送到外部服务。如果团队对数据出网没有严格限制，API 模式是最快看到效果的方式——只需要一个 API Key，改两个环境变量，就能把整套平台跑起来。
注意：如果选择本地推理模式，务必确认推理框架对 GPU 的透传支持。NVIDIA 显卡需要先安装驱动和容器工具包，否则 GPU 无法在容器内使用，推理会回退到 CPU，速度慢到几乎不可用。这个坑我踩的时候浪费了整整一个晚上。
3.2 Agent 核心编排：任务规划与工具调用
Harness 的灵魂在于任务规划引擎。它采用类似 ReAct 模式的循环机制：思考（Thought）→ 行动（Action）→ 观察（Observation）→ 再思考，直到任务完成或达到最大轮次。在实操中，这表现为后台日志里一串结构化记录，每一条都包含模型思考的内容和选择的工具。
工具注册是另一个要点。Harness 默认内置了一批常用工具，比如网络搜索、文件读写、代码执行等。但在局域网场景中，最有价值的是自定义工具。比如我封装了一个内部文档检索工具，把公司 Wiki 的索引目录暴露给 Agent，它就能在回答问题时主动查阅内部文档，而不是只靠模型自身的知识。工具的定义非常简单——写一个带有明确文档字符串和函数签名的 Python 函数，然后在配置文件里注册即可。
在实际配置过程中，需要注意工具描述的措辞。模型通过工具描述来决定“什么时候该用这个工具”，描述越具体，调用越准确。一个典型的差示例是“search_docs”，好的描述应该是“当用户询问关于内部项目X的文档、手册、规范时，使用此工具进行全文检索，传入关键词，返回文档片段列表”。这句描述会影响 Agent 是否在正确时机选择该工具，是调用准确率的关键因素。
3.3 可视化界面的交互设计
可视化界面不是单纯的“聊天窗口”，它是一个 Agent 任务控制台。界面主要有三块功能：对话交互区，用户可以描述任务目标；任务状态区，展示当前任务经过哪些步骤、调用了哪些工具、每个步骤的输出是什么；执行结果区，展示任务的最终输出，可能是文字、表格或文件链接。
使用 Agent 平台的体验和使用普通聊天机器人完全不同。普通聊天是“一问一答”，Agent 平台是“下发指令-观察执行-校验结果”。用户在界面里可以直接看到 Agent 的思考过程和工具调用记录，如果某一步执行偏离了预期，可以立即中断任务并调整指令。这个透明度对于建立信任非常重要——如果用户看不到内部执行过程，很难放心让 Agent 处理实际任务。
界面层还有用户管理功能，支持简单的账号配置，避免局域网内任意机器都能访问。这层控制在普通场景下用最简单的基础认证就足够，不需要引入复杂的权限体系。
4. Docker Compose 实操：从零搭建完整环境
4.1 环境准备与硬件评估
动手之前先确认硬件和系统环境。最低配置建议是 4 核 CPU、16GB 内存、20GB 磁盘剩余空间。如果要本地跑模型，需要一张 NVIDIA 显卡，显存不小于 12GB（推荐 16GB 以上）。内存方面有个容易忽略的点：模型推理时除了显存，CPU 内存也需要预留，因为加载模型文件、处理输入输出、运行没有卸载到 GPU 的部分算子都需要内存，建议系统内存不低于显卡显存的 1.5 倍。
操作系统方面，主流 Linux 发行版都可以，我用的是 Ubuntu 系的系统，内核版本较新，对容器和 GPU 驱动的兼容性比较省心。需要提前装好的软件只有两个：Docker Engine 和 Docker Compose 插件。GPU 支持需要额外安装 NVIDIA 驱动以及对应的容器运行时。检查驱动是否安装成功的命令是nvidia-smi，能看到显卡信息表说明驱动没问题；然后在 Docker 里跑一个带--gpus all参数的测试容器，能识别到 GPU 才算容器侧准备完毕。
网络方面，服务器需要有一个固定的局域网 IP，这也是团队访问的基础。可以在路由器上给服务器做静态 DHCP 绑定，避免 IP 变更导致同事收藏的链接失效。
4.2 目录结构与 Compose 配置
目录结构直接决定后续维护的清晰度。我的项目目录是/opt/deepseek-harness，下面分几个子目录：data用来存放持久化数据，包括数据库文件和上传文件；config存放各种配置文件；logs存放容器日志；tools用来放自定义工具的代码目录。这个结构的好处是备份很容易——只需要打包整个项目目录，就可以在任何一台新机器上恢复整套环境。
下面是一个典型的docker-compose.yml配置，包含核心服务骨架。需要注意的是，实际部署时应根据 Harness 服务的具体配置项进行调整，这里给出可参考的框架：
version: "3.8" services: ## 模型推理服务：本地加载模型，对外提供兼容接口 model-server: image: model-server-image:latest container_name: deepseek-model ports: - "8001:8001" volumes: - ./data/models:/models - ./data/cache:/cache environment: - CUDA_VISIBLE_DEVICES=0 - MAX_MODEL_LEN=8192 - QUANTIZATION=awq deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] restart: unless-stopped ## Harness 核心引擎：Agent 编排与 API 服务 harness-engine: image: harness-engine-image:latest container_name: deepseek-harness depends_on: - model-server ports: - "8080:8080" volumes: - ./config:/app/config - ./tools:/app/tools - ./data:/app/data - ./logs:/app/logs environment: - MODEL_BASE_URL=http://model-server:8001/v1 - MODEL_API_KEY=local - MODEL_NAME=deepseek-local - AGENT_MAX_ITERATIONS=10 - TOOL_TIMEOUT=30 restart: unless-stopped ## Web UI 服务 web-ui: image: harness-webui-image:latest container_name: deepseek-webui depends_on: - harness-engine ports: - "3000:3000" environment: - API_BASE_URL=http://harness-engine:8080 restart: unless-stopped配置中几个关键参数值得展开解释。MODEL_BASE_URL指向模型服务的容器内地址，Docker Compose 的默认网络里，容器之间可以通过服务名互相访问，这里不需要写局域网 IP，直接写服务名model-server即可，这是容器网络和主机网络最大的区别之一。AGENT_MAX_ITERATIONS控制单个任务最多执行多少轮思考-行动循环。设置太短会导致复杂任务中途失败，设置太长会让简单任务陷入的“无意义循环”难以终止，默认值 10 在实际使用中是个不错的平衡点。TOOL_TIMEOUT是单次工具调用的最大耗时，超过则视为失败，避免某个工具卡死拖住整个 Agent。
4.3 启动流程与验证
环境准备完成后，启动流程非常直接。第一步，把项目目录放到服务器上，检查配置文件的路径是否正确。第二步，拉取镜像并启动：在项目目录下执行docker compose up -d，加-d参数让所有服务在后台运行。第一次启动时，模型服务会加载模型文件，根据模型大小和磁盘读取速度，这个过程可能需要几分钟，可以通过日志观察加载进度。
第三步验证状态。执行docker compose ps查看所有容器的状态，如果全部显示Up，说明容器本身没有问题。验证模型服务是否正常：在服务器上执行curl http://localhost:8001/v1/models，应该返回模型列表的 JSON 数据。验证 Harness 服务：执行curl http://localhost:8080/health，应该返回健康状态。最后在浏览器里输入http://服务器局域网IP:3000，能看到登录页面说明前端正常。
提示：如果某一步验证失败，不要急着改配置重启所有容器，先看日志。执行
docker compose logs + 服务名定位具体服务的问题。最常见的启动失败原因是模型服务加载超时——模型文件大、磁盘慢、容器健康检查的等待时间不够，都可能让 Harness 依赖的服务在启动初期断连。解决方法是适当加大depends_on的条件等待，或先单独启动模型服务，确认接口通了再启动整个集群。
5. 局域网访问与数据配置实战
5.1 网络模式与端口规划
对于局域网部署，我强烈建议使用 Docker 默认的桥接网络。桥接网络的优点是端口隔离清晰、容器间通过内部网络通信更安全。端口规划要遵循一个原则：端口越集中越容易记忆。我的方案中，Web UI 固定使用 3000 端口，Harness API 使用 8080 端口，模型服务使用 8001 端口。这些端口可以在服务器防火墙中仅放行3000让局域网用户访问，其余端口只允许本机访问，减少暴露面。这个设计在内部场景够用，同时也避免多人访问时复杂度上升。
内网访问的地址格式是http://服务器IP:3000。如果不想让同事记 IP，可以在内网 DNS 服务器上添加一条 A 记录，或者干脆在一台常开的机器上配置一个简单的主机名映射。我在实际环境里直接更新了路由器内置 DNS，效果很稳定。
如果不介意在局域网内再加一层访问控制，还可以在 UI 服务前加一个简单的反向代理，增加一层 Basic Auth。这里的配置也很轻量，一个配置文件就能实现，不需要专门的中间件服务。
5.2 GPU 透传与资源限制
GPU 透传是最容易出问题也最值得提前验证的部分。NVIDIA 容器运行时安装步骤大致是：安装 NVIDIA 驱动并确认nvidia-smi正常输出，然后配置容器运行时，最后在 Docker 的 daemon 配置中将其设为默认运行时，重启 Docker 服务。完成这些步骤后，在 Compose 文件的deploy.resources.reservations.devices里声明 GPU 资源，容器启动后就能在容器内看到显卡。
资源限制同样重要。为了防止某个容器把主机资源耗尽，可以在 Compose 中为每个服务配置deploy.resources.limits，比如限制内存上限、CPU 份额。模型推理服务对内存比较敏感，建议设置一个明确的上限，比如 16GB，避免模型在长上下文对话中无限制占用内存。如果主机有多张显卡，可以给不同服务分配不同的CUDA_VISIBLE_DEVICES，注意这里的编号和主机的 GPU 序号对应关系，弄错了服务会直接不可用。
5.3 数据持久化与备份策略
容器本身是无状态的——容器退出后，容器内写过的文件全部消失。因此所有需要保留的数据都必须存储在挂载的卷中。我在配置里把模型的权重目录、向量数据库文件、日志、工具代码都做了挂载，这样无论容器怎么重启，数据都在。
备份策略上，我的做法是每天凌晨用tar打包整个项目目录到另一块磁盘，保留最近 7 天的版本。因为整体体积不大，一个完整的备份通常只需要几分钟。需要特别说明的是，模型权重文件一般体积较大且不频繁变化，备份策略可以将这个目录单独排除，让备份只包含配置、数据库和日志，能大幅缩短备份时间并减小备份文件体积。实际操作中，备份数据库才是重中之重——一旦数据丢失，Agent 的工作历史、知识库索引全部白费。
6. 常见问题与排查技巧实录
6.1 模型加载慢与显存不足
两个问题在资源受限的服务器上几乎必现。模型加载慢，常见原因是模型文件放在机械硬盘上，几百 GB 的读取速度远低于固态硬盘，容器在等待模型加载完成之前会一直处于启动中状态。排查技巧：先用htop或docker stats观察容器是否在大量进行磁盘 I/O；如果确认是磁盘瓶颈，把模型文件迁到 SSD 上最直接。
显存不足表现为推理时报错或容器直接崩溃。排查显存占用用nvidia-smi，查看显存总量、已用、进程列表即可。如果显存确实不够，有以下选择：换用量化级别更高的模型（从 8bit 降到 4bit）；缩小上下文窗口；减小并发请求数，在配置里将最大并发连接数限制到 1。如果这些仍然不够，就需要接受 API 模式。
6.2 局域网访问失败
最常见的现象是：服务器本机用curl访问服务正常，但局域网内其他电脑浏览器打不开页面。99% 的原因是服务器防火墙拦截了端口。排查时先确认防火墙状态和放行规则，然后从另一台电脑执行telnet 服务器IP 3000测试端口连通性；如果显示无法连接，基本可以确定是防火墙。处理方式有两种：直接放行对应端口（内网安全性可控，这个是常见做法），或者把服务绑定在0.0.0.0上然后统一通过防火墙配置入口。另外，如果服务器有多个网卡，需要确认 Docker 端口映射时绑定的 IP 是不是对外提供服务的那张网卡。
6.3 Agent 任务循环异常或工具调用失败
任务循环异常是 Agent 类应用最有意思也最头疼的问题。现象是：Agent 陷入反复调用同一个工具，或者执行完全相同的一步骤却得到了相同的错误结果，直到达到迭代上限。排查时先看后台日志中模型“思考”部分的内容——通常会看到不同轮次里出现了类似的措辞，说明模型没有从工具返回的结果中获得新信息。解决办法有三类：调整工具描述，使其更贴近真实场景的需求；为工具增加更严格的输入格式校验（当工具反复收到非法参数时，模型往往是因为没有理解参数结构，此时可以把“参数示例”直接写进工具描述）；设置更小的迭代上限，避免无意义循环拖长时间。
工具调用失败的另一大原因是超时。默认 30 秒超时对一些慢速工具（比如涉及大数据量查询的数据库工具）不太够，需要按工具类型单独配置超时时间。我的做法是把工具按速度和可靠性分类：快速可靠的工具超时不超过 10 秒，慢工具 60 秒以上，并在工具描述里注明“可能需要较长时间”。
6.4 容器重启后数据丢失或配置失效
“容器重启后数据丢失”通常不是容器重启导致的，而是修改了 Compose 配置之后执行了docker compose down而没有重新挂载卷，或者挂载路径写错，数据实际写入了容器可写层。排查方法：执行docker inspect 容器名，查看Mounts部分列出的挂载源目录和目标目录是否匹配，如果某个卷没有出现在配置里，立即重建对应服务。
配置失效多半是环境变量拼写错误或版本升级后配置项改名。还有一种隐蔽情况是容器内部缓存了旧配置，重启时不强制重新创建容器。此时用docker compose down && docker compose up -d，强制重新创建容器，把配置重新读一遍，问题基本解决。
6.5 排查技巧速查表
| 现象 | 优先排查项 | 常用命令 |
|---|---|---|
| 容器一直启动失败 | 日志、模型文件路径、GPU 驱动 | docker compose logs、nvidia-smi |
| 本地正常、局域网不通 | 防火墙、端口映射网卡 | telnet、firewall-cmd --list-all |
| Agent 反复执行同一工具 | 工具描述、输入参数、日志中的思考内容 | docker compose logs harness-engine |
| 工具调用全部超时 | 超时配置、工具本身性能 | docker compose logs |
| 容器重启后数据丢失 | 挂载卷、compose 配置 | docker inspect |
| 模型对话速度极慢 | CPU/GPU 使用、是否跑在 CPU 上、并发限制 | docker stats、nvidia-smi |
7. 扩展玩法与个人实操体会
7.1 接入更多模型与多 Agent 协作
这套环境跑通之后，扩展模型非常容易。Harness 对接模型走的是标准兼容接口，在同一配置里可以定义多套模型连接：一个本地模型负责日常问答，一个 API 模型处理复杂推理任务，还可以接入更快的轻量模型做意图识别。在 Agent 的配置中指定不同任务类型使用不同模型，相当于给不同的“岗位”安排了不同专长的员工。
多 Agent 协作是我目前正在尝试的方向。思路是：一个“调度 Agent”负责接收用户需求并分类，把子任务分发给多个“执行 Agent”，各执行 Agent 再通过工具完成任务后将结果汇总。这种模式下，每个 Agent 只需要关注自己的领域，任务完成率和结果质量都明显提升。在局域网内部，这种编排方式特别适合“部门内部多系统操作”，比如一个 Agent 查数据库、一个 Agent 生成文件、一个 Agent 发通知，协同完成整个流程。
7.2 自定义工具与知识库接入
自定义工具是让 Agent 平台真正变得有用的关键。我给团队接入的第一个工具是“内部服务状态查询”，封装了一个脚本，能够读取系统监控接口的数据并格式化输出。上周有人问“某个系统最近有没有报错”，Agent 自动调用这个工具，十几秒就给出了准确答案，而不是靠模型模糊猜测。这个反馈给了我很大信心——Agent 在你给它配好工具之后，是能真正替代不少机械性工作的。
知识库接入同理。把团队文档导入向量数据库，挂载为检索工具，Agent 在回答问题时就能基于真实文档而不是泛泛而谈。操作上比自定义工具稍复杂，但收益很大。接入知识库后有一个明显差别：之前 Agent 对内部术语的解释含糊不清，现在可以引用具体文档段落，准确率提升非常多。
7.3 我在这个项目中踩过的几个坑
第一个坑是 GPU 透传。最开始容器无法识别 GPU，我以为是驱动问题，反复重装了两遍，后来才发现容器运行时没有正确配置。这个教训是：遇到“容器内无法使用 GPU”时，先用官方提供的测试镜像跑一个 demo 容器，确认基础链路是通的，再回来看自有镜像，不要一上来就怀疑驱动而重装。
第二个坑是模型服务与 Harness 之间的健康检查顺序。我最初的 Compose 里只写了depends_on，但这个指令只保证“模型服务容器启动了”，并不保证“模型已经加载完毕”。Harness 在模型还没就绪时就开始发起请求，所有请求全部失败。后来我把健康检查加上，并在 Harness 里加了自动重试逻辑，问题才彻底解决。建议所有依赖服务之间都增加类似的健康检查和容错机制。
第三个坑和工具超时有关。最初给所有工具统一设置了 5 秒超时，结果查询类工具频繁失败。有个同事反映 Agent “老是答非所问”，查日志才发现很多步骤是因为超时被强制中止，Agent 在“部分失败”的状态下继续推理，结果自然不理想。给工具按耗时分类配置超时之后，任务完成的稳定度立竿见影。
最后一个体会是团队的使用预期管理。Agent 平台本质上是一个需要对话式交互的自动化工具，不能期望它像魔法一样完美。部署完成后，我给团队提供了“任务描述模板”，引导大家在提需求时写明目标、输入、产出物，成功率比自由发挥高出一大截。再好的平台，也要有合适的使用方式才能真正发挥价值。
