从碎片概念到 Harness
接入 DeepSeek 之后，最容易混的不是 API，而是这些词：Harness、编排、Agent、OpenClaw。这篇把碎片概念对到 TourMate 出行助手上。
对标过的好形态都是同一条链：自然语言 → 系统里的真实实体 → 可点击动作。医院挂号说症状推荐科室，健康餐助手用 App 里真实在售的餐品组周套餐——模型不编造库存。TourMate 也是：说「赛里木湖，预算 2000」，查出平台里的真活动，而不是让模型编一个团。
DSH 到底是什么
可以理解成这个公式：
DeepSeek 模型 + Harness = Agent模型本身只会“生成文本/工具调用意图”；Harness 负责把它变成一个能连续执行任务的系统。公开文章里也反复提到这个边界：Harness 覆盖模型之外的上下文管理、工具 API、子 Agent、多 Agent 工作流、评估和反馈等系统层能力；AgentWay 就把它概括为“model 之外的一切”。DeepSeek 官方 API 文档也能看出为什么需要 Harness：工具调用、思考模式、reasoning_content 回传、上下文缓存这些细节，裸接 API 很容易踩坑，见 Thinking Mode、Tool Calls、Context Caching。
它能做什么 DSH 这类 Harness 通常负责这些事：
- 管理 Agent 循环：模型思考、决定调工具、执行工具、读取结果、继续下一轮。
- 接入工具：文件读写、Shell、搜索、MCP、浏览器、数据库、第三方 API。
- 管理上下文：历史压缩、长上下文、缓存命中、会话恢复。
- 处理 DeepSeek 特有协议：比如思考模式下有工具调用时，后续请求必须带回
reasoning_content，否则可能 400。 - 做安全控制：命令审批、沙箱、权限分级、成本上限、执行日志。
- 支持子 Agent/并行任务：把复杂任务拆给多个 Agent 并行做。
- 提供 UI 或 Headless Runtime：CLI、TUI、Web、桌面端、MCP server 都可以是入口。
为什么最近火 核心原因是大家发现：便宜、长上下文、强推理的模型只是底座，真正能对标 Claude Code、Codex、Cursor 的，是“模型 + 工具 + 工程化运行时”。DeepSeek 这边又有 V4、思考模式、上下文缓存、Agent 工具适配这些组合拳，所以社区把 Harness 当成 DeepSeek 做 Agent 产品的关键一层。最近也有媒体报道 DeepSeek Harness 内测传闻，但这种消息目前公开可验证信息有限，要谨慎看待。
然后我就想到了我现在助手里面的内容：
搭子出行助手对话流程图
基于这个流程图实现，我其实思维还是混乱的，我不知道这到底到了程度。我只是接入了一个 LLM，然后 LLM 在里面做的事又微乎其微。 我这里引用下 codex 的回复：
你 TourMate 里接入 DeepSeek 模型，已经是在做 AI 应用了；但它更准确地说是一个“LLM 辅助的业务工作流”，还不一定是完整 Agent Harness。你图里的流程其实很清楚：
用户说： “我最近想去赛里木湖玩，预算 2000 以内”
你的系统做了：
- 调一次大模型：
extractSearchIntent - 让模型把自然语言翻译成结构化 JSON：
intent / keywords / date / maxPrice - Java 根据 intent 分流
- Java 查数据库，不是模型查
- Java 拼模板、补小贴士、审计 trace/token/耗时
- 最后返回给用户
所以这叫：
LLM-powered assistant / AI 助手 / AI 应用 / LLM + Workflow
更具体一点：
你没有让模型“自由行动”，而是让模型只负责最不确定的那一步：理解用户话里的意图和槽位。后面的分流、查库、兜底、审计，全是你用 Java 确定性控制。
这其实是很好的架构。
几个词的分层LLM：大模型本身。比如 DeepSeek、GPT、Claude。它本质上是“语言推理/生成引擎”，输入上下文，输出文本、JSON 或工具调用意图。
AI Assistant：你做的聊天助手。它有 UI、接口、prompt、业务逻辑。TourMate 就是这个。
Workflow / 流程编排：你图里的流程。它不是玄学，就是把“什么时候调用模型、什么时候查库、什么时候追问、什么时候兜底”写成可控流程。它的价值是：让模型只做适合模型做的事，让代码做必须稳定的事。
RAG：先检索，再让模型回答。比如你先从活动库、攻略库、景点库查出候选内容，再把这些内容塞给模型，让它生成自然语言推荐。RAG 的重点是：模型不要凭空知道你的业务数据，而是看你给它的资料回答。
Tool Calling / Function Calling：模型不直接执行动作，而是说：“我想调用 searchActivities，参数是 { destination: "赛里木湖", maxPrice: 2000 }”。真正执行的是你的 Java/Node/Rust 代码。
Agent：比普通 workflow 更进一步。Agent 通常是一个循环：模型思考、选择工具、执行工具、观察结果、再决定下一步。比如它可能先查活动，再查天气，再查交通，再预算估算，最后生成计划。它比固定流程更灵活，但也更难控。
Harness：这就是最容易混乱的词。Harness 不是模型，也不是业务功能。它是把模型包装成 Agent 的运行时外壳。通常负责：上下文管理、工具注册、权限、沙箱、记忆、流式事件、trace、错误恢复、多轮循环、成本统计、子任务等。
所以：
模型：DeepSeek
助手：TourMate AI 助手
工作流：你画的 SEARCH_ACTIVITIES / RECOMMEND / OUT_OF_SCOPE 分流
工具：searchActivitiesAdvanced、SQL 查询、活动推荐 API
RAG：查出活动/攻略后喂给模型总结
Agent：如果模型能多轮自主决定查什么、调用什么、是否继续
Harness：支撑这个 Agent 跑起来的一整套运行时DeepSeek Harness 是什么 DeepSeek Harness 可以理解成：DeepSeek 想做的 Agent 运行时/产品外壳，类似“让 DeepSeek 不只是聊天，而是能使用工具、管理上下文、执行任务”。
公开资料里 OpenClaw 文档对 harness 的定义很直白：agent harness 是“执行一次准备好的 agent turn 的低层执行器”，不是模型提供商，也不是工具注册表。参考 OpenClaw Agent Harness Plugins。OpenClaw 自己也有 agent runtime，负责 agent loop、工具接线、prompt 组装等，见 OpenClaw Agent Runtime。
这说明一个关键点：
Harness 不是“让大模型变聪明”的咒语，而是“让模型能稳定、安全、可观测地干活”的工程系统。
OpenClaw 又是什么 OpenClaw 更像一个 Agent 平台/网关。它可以管理不同 agent runtime，也可以接外部 harness，比如 Claude Code、Codex、Gemini CLI、OpenCode 等。它自己文档里也说 ACP 路径可以运行外部 coding harness，参考 OpenClaw ACP Agents。
你可以把它理解成：
OpenClaw：Agent 平台/调度层
Harness：某一种 Agent 执行器
DeepSeek Harness：围绕 DeepSeek 模型做的 Agent 执行器
DeepSeek：底层模型大模型到底怎么“会做事” 它其实不会真的“查活动、订票、读数据库”。它会的是：
- 从语言里推断用户意图
- 生成结构化参数
- 根据上下文推理下一步应该调用什么
- 把查到的信息组织成自然语言
真正做事的是你的系统。
比如：
用户：预算 2000，想去赛里木湖
模型：输出 { intent: "SEARCH_ACTIVITIES", destination: "赛里木湖", maxPrice: 2000 }
Java：查 activities 表
Java：得到 5 条活动
模型/模板：整理成推荐话术这里模型看起来很智能，是因为它很擅长把模糊语言翻译成结构化意图。但它不知道你库里真实有什么活动，除非你查出来给它。
你现在这个算什么 我会给 TourMate 当前架构这样定性：
TourMate 是一个旅游垂直场景的 AI 助手，核心架构是“LLM 意图抽取 + Java 确定性业务编排 + 数据库检索 + RAG/模板回复”。
如果你后面升级成这样：
模型自己判断：
先查目的地活动
再查天气
再查交通
再根据预算过滤
不够信息就追问
查完再生成 itinerary
失败后换策略那就越来越接近 Agent。
如果你再加上：
工具注册
权限控制
多轮上下文压缩
trace
token 成本
工具调用事件流
插件/MCP
长期记忆
子任务调度那这层就叫 Harness。
你可以记一个最简单的判断：
只调模型回答：Chatbot
模型抽 JSON，代码分流：LLM Workflow
模型能选工具并多轮循环：Agent
把 Agent 跑稳、跑安全、跑可观测的底座：Harness你的图里那次大模型调用，本质上就是 NLU/意图抽取器。你写的流程编排，是在把不稳定的自然语言能力关进一个稳定的业务管道里。这不是“低级”，反而是大多数生产级 AI 应用最靠谱的形态。
tourmate-assistant 单一意图助手
目前我的助手比较单一，只能帮我查下活动，那为什么 chatgpt 就这么智能了，那是因为 chatgpt 背后做了很多事，这些东西都不是封装打了 LLM 本身。LLM 本身能做什么事了，上面提到：
大模型本身。比如 DeepSeek、GPT、Claude。它本质上是“语言推理/生成引擎”，输入上下文，输出文本、JSON 或工具调用意图。 会理解、推理、写作、总结ChatGPT 看起来“没有它不会的”，不是因为裸模型真的什么都能做，而是因为它背后已经接好了很多能力：
大模型本身：会理解、推理、写作、总结
搜索/浏览工具：查最新信息
代码工具：算东西、跑脚本、处理文件
文件工具：读 PDF、Excel、图片
记忆/上下文：知道前面聊过什么
安全/权限/审计：控制它能不能做某些事你现在的 TourMate 只有其中一小块：
用户自然语言
→ LLM 抽 intent JSON
→ Java 查活动
→ 返回真实活动卡片所以它能回答“赛里木湖 2000 以内活动”，但不能自然回答“查天气”“做三天攻略”，不是因为你的助手不是 AI，而是因为你还没给它接这些工具和流程。
天气怎么做 天气不是让模型凭空回答。应该是：
用户：明天赛里木湖天气怎么样？
LLM：抽取 { intent: WEATHER, location: 赛里木湖, date: 明天 }
Java：调用天气 API
LLM/模板：把天气结果说成人话这里真正查天气的是天气 API，不是模型。
旅游攻略怎么做 旅游攻略可以分三档：
轻量版：
LLM 根据常识生成攻略
缺点：可能不准，容易泛泛而谈
靠谱版：
查你平台活动 + 查天气 + 查景点/交通资料
再让 LLM 组合成攻略
产品版：
用户偏好 + 平台活动 + 天气 + 预算 + 天数
生成行程，并且每个活动都能点击到真实详情所以“做旅游攻略”不是一个魔法能力，而是一个 workflow：
抽取目的地/天数/预算/偏好
→ 查活动
→ 查天气
→ 查景点资料或攻略知识库
→ 预算过滤
→ 生成每日安排
→ 返回卡片 + 文案这就是你看到的“流程编排”。它不是单纯“约束模型”，而是：
决定哪些事交给模型，哪些事交给代码，哪些事交给工具，最后怎么组合结果。
你现在不需要做 DeepSeek Harness 那种大而全的东西。你真正需要的是把自己的助手从：
单一意图助手升级成：
多意图 + 多工具 + 固定工作流的旅游助手建议你下一步这样拆：
Intent 类型：
SEARCH_ACTIVITIES 查活动
RECOMMEND_DESTINATION 推荐目的地
QUERY_WEATHER 查天气
MAKE_TRAVEL_PLAN 做攻略/行程
OUT_OF_SCOPE 拒答或引导
Tools：
search_activities 查平台活动
get_weather 查天气
get_activity_detail 查活动详情
get_destination_info 查目的地资料，后续可 RAG
build_itinerary 组装行程，代码/LLM 都可参与然后每个意图先写死稳定流程。不要一上来做“模型自由决定所有步骤”的 Agent Loop。比如：
查活动：LLM 抽槽 → Java 查库 → 卡片
查天气：LLM 抽地点日期 → Java 调天气 → 回复
做攻略：LLM 抽目的地/天数/预算 → 查活动/天气/资料 → LLM 生成攻略等这些稳定了，再考虑更 Agent 化：
模型自己判断要不要先查天气、再查活动、再追问用户这时你才慢慢接近 Harness 的形态。
一句话帮你定心：
你做的不是“低配版 ChatGPT”，而是“垂直领域 AI 助手”。ChatGPT 是通用工具箱，TourMate 应该是会查真实活动、能跳转下单、懂你业务边界的出行助手。
你现在最应该追的不是 DeepSeek Harness，而是把 TourMate 做成一个小而稳的 Tool-augmented AI Assistant。这条路很正。