xAgent Agent Harness（上）：会话如何理解任务变化并调整执行环境
很多 Agent 系统把 Harness 描述成一个循环：把用户消息交给模型，执行模型返回的 Tool Call，再把结果送回模型。这个循环很重要，但它还没有回答另一个更早的问题：当用户继续发消息时，这条消息是在延续当前任务、进入同一任务的新阶段，还是已经超出当前会话的职责？
xAgent 把这部分放在业务 Agent 执行之前处理。原始输入先进入会话并成为稳定事实，系统再判断任务关系、维护会话目标，并在确有需要时调整 Skill 和 Tool。业务 Agent 看到的是已经对齐的任务状态和执行环境，而不是一组在会话创建时永久固定的能力。
DeepSeek Harness 任务编排与 xAgent 的共同边界
DeepSeek Harness 官方页面将 Agent 概括为 Model 与 Harness 的组合，并把模型、Tool、Skill、Session、Sandbox、Storage、Loop、Scheduling 和 UI 都放进可组合的插件体系。其官方架构文档进一步把 Session 表达为追加式事件日志，把 Agent Loop 拆成可替换的模型适配、Tool 注册、Session 和循环组件。
因此，DeepSeek Harness 任务编排 不是“给 DeepSeek 模型接几个 Tool”的同义词。它讨论的是模型调用之外，谁负责保存会话事实、装配能力并让任务连续推进。xAgent 解决的是同一层问题，但采用了自己的责任划分：
| 对照维度 | DeepSeek Harness | xAgent |
|---|---|---|
| 运行时组合 | 通过插件树和 Profile 组合模型、Tool、Skill 与运行组件 | 为每个 Session 维护实际加载的 Skill、Tool 与运行策略 |
| 会话连续性 | 追加式 Session 事件日志是上下文来源 | SessionEngine 持有历史、阶段目标、全局目标和运行状态 |
| 任务编排入口 | Agent、Session 与插件共同构成可替换的运行路径 | 先判断新输入与当前阶段、会话目标的关系，再决定是否调整能力 |
| 主要边界 | 强调插件和核心运行组件之间的契约 | 强调 Brain、SessionEngine 与业务 Agent 之间的事实责任 |
两者的共同原则是：模型只是执行参与者，Harness 才负责连续性和能力装配。区别在于，DeepSeek 的公开设计重点是插件化运行时；本文聚焦 xAgent 如何在业务 Agent 启动前理解一次任务变化。xAgent 不是 DeepSeek Harness 的分支或前端，这里只做同一架构问题下的事实对照。
为什么普通 Tool Loop 不够
假设一个会话正在“研究 ComfyUI 并交付 Markdown 指南”，用户接下来可能发送三种消息：
继续：仍然是当前阶段。把刚才的 Markdown 转成 Word：长期目标仍然相关，但进入了新的交付阶段。顺便帮我查一下明天的天气：已经超出这个专业会话的职责。
如果系统只对最新一句话提取关键词，继续 几乎没有可用语义；如果每条消息都重新选择全部能力，普通补充也会造成不必要的环境抖动；如果直接用新消息覆盖旧目标，专业会话又会逐渐失去原来的责任边界。
因此，xAgent 将“这条消息与当前任务是什么关系”和“这个任务需要什么能力”拆成两个问题。
两级目标描述会话任务
执行会话保留两个不同层级的目标：
| 目标 | 表达什么 | 何时变化 |
|---|---|---|
| 会话全局任务目标 | 这个会话长期负责的业务范围和预期结果 | 会话职责真正变化时 |
| 当前阶段任务目标 | 全局目标下正在推进的当前步骤或交付阶段 | 进入新阶段、补充或修正当前工作时 |
例如，“研究 ComfyUI 并交付完整指南”可以是会话全局目标，“整理节点连接关系”是当前阶段。转为 Word 交付时，当前阶段可以变化，但会话仍然属于同一个研究任务。
这两个目标是会话运行态的稳定事实。上下文摘要可以引用它们来保持连续性，但摘要不能反向覆盖目标；Plan 和 Task 的完整结构也继续由各自的事实责任方维护，不会复制进会话目标。
原始输入必须先成为事实
xAgent 不会在消息刚到达 Channel 时立即做相关度判断。消息先进入 Session 队列，Brain 取得该 Session 的唯一执行权，SessionEngine 按实际消费顺序绑定下一条输入并写入历史，然后才开始语义判断。
用户或会话协作输入
-> SessionEngine 排队并保存原始输入
-> Brain 取得当前 Session 的唯一 runner
-> SessionEngine 绑定下一条任务输入
-> 判断任务关系
-> 对齐任务状态与能力环境
-> 进入业务 Agent loop
这个顺序解决了两个问题。第一，任何辅助模型失败都不能让用户原始消息消失。第二，同一会话快速收到多条消息时，每条消息都基于前一条已经提交的最新任务状态判断，而不是读取消息到达瞬间的过期状态。
审批结果、Tool 结果、系统通知和确定性命令不会进入这条任务相关度链。它们各自沿已有的审批、执行或控制路径处理，避免被误判成新任务。
相关度 Agent 只提供信号
xAgent 使用一个内部、无状态的任务相关度 Agent。它只接收：
- 当前用户原始消息及稳定资源引用；
- 当前阶段任务目标；
- 会话全局任务目标。
它不接收完整 History、候选 Skill、候选 Tool、Memory、执行步骤或已有编排结果。输出也只有两个分数：当前消息与当前阶段的相关度，以及与会话全局目标的相关度。
相关度 Agent 不生成新目标，不推荐 Skill，不决定是否压缩，也不直接修改会话。它只是把一个难以用字符串规则完成的语义比较，转换成受约束的运行时信号。真正的状态变化仍由 Brain 根据分数和确定性运行状态选择，并通过 SessionEngine 的业务动作提交。
两个维度如何选择后续流程
对外理解这套逻辑时，不需要依赖具体阈值。高、低和不确定三个区间形成以下决策边界：
| 当前阶段相关度 | 全局目标相关度 | 默认解释 | 系统行为 |
|---|---|---|---|
| 高 | 高 | 当前工作的继续、补充或修正 | 保持任务和能力环境，继续执行 |
| 低 | 高 | 同一职责内的新阶段 | 更新阶段目标，按需调整能力，并评估是否压缩上一阶段 |
| 低 | 低 | 新任务或职责范围外请求 | 不覆盖当前会话目标和能力，保留给责任路由重新判断 |
| 高 | 低 | 阶段与全局目标可能冲突 | 保留现状，不自动替换目标 |
| 不确定 | 任意 | 信号不足以支持状态变化 | 保留上下文和能力，由业务 Agent 判断或询问用户 |
分数不是业务事实，也不会默认写入会话目标或上下文摘要。这样可以调整评分模型和阈值，而不把一次模型判断变成永久状态。
任务状态与能力环境分开变化
任务发生变化，不代表执行环境一定要重建。用户修正文案、补充一个约束或要求继续当前工作时，现有 Skill 和 Tool 通常仍然适用，xAgent 会直接保留它们。
任务首次初始化或进入新阶段时，才进入环境准备链：
已经对齐的完整任务
-> 提取用于召回的任务要点
-> 召回 Skill、ToolSet 和 Memory 候选
-> Orchestrator 从候选中选择目标能力
-> SessionEngine 差异更新当前 Skill 和 Tool
下面是一条客服运营周报任务在环境准备阶段的真实状态。任务要点提取、相关 Skill、Tool 与 Memory 查找，以及能力编排被投影为彼此独立的阶段：
任务要点只用于候选召回，不会和完整任务一起重复进入 Orchestrator。调整模式会同时携带当前能力，Orchestrator 可以保留仍然适用的选择，只对目标环境做差异调整。它只消费一份规范化任务、当前能力和已经召回的候选集合，也不创建 Session、不改写任务目标、不选择模型或 Agent 身份。
这种拆分避免了三个模型角色互相覆盖：相关度 Agent 判断消息关系，任务语义提取负责召回，Orchestrator 负责能力选择。会话事实仍由 SessionEngine 维护。
编排完成后，实际加载到会话中的能力仍然可以检查。这个任务最终选中了数据可视化与周报 Skill，并加载了计划、能力发现和文件读写工具：
接收任务的会话自己准备环境
新版链路也改变了子会话的创建方式。主会话负责判断是否已有合适的责任会话；确实需要新会话时，session_create_sub 只创建一个具备确定性默认配置和最小能力的可运行会话，并原样移交任务消息与资源引用。
创建方不再提前替子会话解释任务、选择业务 Skill 和 Tool，或者生成一套执行 Prompt。子会话收到任务后，和普通用户输入一样进入统一的任务控制循环，由实际承担工作的会话初始化自己的目标和能力环境。
这让“谁执行任务，谁理解任务”成为稳定边界，也让环境编排失败不再阻止会话创建和原始任务移交。多会话之间如何传递任务与材料，可继续阅读多 Agent 会话事件协作。
辅助判断失败不能接管主流程
任务相关度判断是一项可退化的前置能力。调用失败、输出不合法或模型暂时不可用时，xAgent 按“没有足够证据改变任务”处理：保留现有目标、能力环境和压缩状态，并继续处理已经保存的用户消息。
环境调整失败与相关度失败是不同问题。已经提交的原始消息和任务状态不能因此丢失，现有能力也不能先被清空再等待一次可能失败的全量重建。系统应保留可恢复事实，让失败在自己的责任边界内收束。
用户可以观察到什么
当消息只是延续当前工作时，用户通常只会短暂看到任务语义理解，然后任务继续执行。当消息进入新阶段并需要不同能力时，时间线会依次显示类似状态：
正在理解任务语义
-> 正在提取任务要点
-> 正在发现任务能力
-> 正在编排任务
-> 正在应用任务环境
这些状态表达当前 Harness 正在推进的阶段，不是模型生成的聊天内容。它们也不意味着每条消息都会走完全部步骤。
能力如何按需进入会话，可阅读AI Agent 如何按需发现和加载工具与 Skill；任务进行中哪些设置从后续模型调用生效，可阅读任务执行中的动态切换。
下一篇：对齐之后怎样持续执行
任务控制循环解决的是“当前消息属于什么任务，以及需要什么环境”。环境准备完成后，业务 Agent 才进入固定的模型与 Tool 执行循环。
下一篇《xAgent Agent Harness（下）：一次任务如何持续执行、暂停与恢复》将继续说明唯一 runner、上下文装配、Tool Call、审批等待、上下文压缩和重启恢复怎样组成同一条执行链。长任务的用户侧组织方式也可先参考AI Agent 如何执行长任务。