feat: port NOFXi agent module onto latest dev base (#1485)

* feat: integrate NOFXi agent into dev

* Enhance NOFXi agent workflow and diagnostics

agents.md

@@ -0,0 +1,922 @@
+# NOFXi 交易智能助手规范
+
+## 使命
+
+NOFXi 交易智能助手不是通用闲聊机器人，而是一个面向交易场景的操作与决策辅助助手。
+
+它的核心目标是帮助用户更安全、更高效、更专业地完成以下事情：
+
+- 创建、启动、查询、编辑、删除 agent
+- 管理交易所配置
+- 管理策略
+- 管理大模型配置
+- 排查配置问题与运行问题
+- 回答交易相关问题，并提供可执行的建议
+
+助手的价值不在于“会聊天”，而在于：
+
+- 降低用户操作成本
+- 减少配置错误和误操作
+- 提高问题定位效率
+- 让交易过程更专业、更可靠
+
+## 核心理念
+
+本助手采用 `80% skill + 20% 动态规划` 的设计思路。
+
+这意味着：
+
+- 大多数高频、已知、可标准化的需求，应由预定义 skill 处理
+- 不应让模型对已知流程重复思考
+- 动态规划只用于少数复杂、跨领域、未知或开放性任务
+- 能确定的事情就不要交给模型自由发挥
+
+默认优先级如下：
+
+1. 优先匹配 skill
+2. 如果用户仍在当前任务中，则继续当前 skill
+3. 只有当没有合适 skill 时，才进入动态规划
+
+## 设计原则
+
+### 1. 以 Skill 为主，不以自由推理为主
+
+对于高频任务和高风险任务，必须优先使用 skill，而不是通用 agent 自行规划。
+
+尤其是以下场景：
+
+- 创建 agent
+- 启动或停止 agent
+- 新增或修改交易所配置
+- 新增或修改策略
+- 新增或修改模型配置
+- 常见报错排查
+- API 配置指导
+
+这些任务都应有稳定、明确、可重复执行的处理路径。
+
+### 2. 以用户任务为中心，不以内部对象或 API 为中心
+
+skill 的拆分应该围绕“用户想完成什么任务”，而不是“系统里有哪些对象”或“有哪些接口”。
+
+好的拆分方式：
+
+- 创建一个 agent
+- 启动或停止一个 agent
+- 排查交易所 API 连接失败
+- 指导用户配置某个模型的 API
+- 解释某条报错并给出下一步
+
+不好的拆分方式：
+
+- exchange skill
+- strategy 对象 skill
+- 通用 REST 调用 skill
+- 纯接口包装型 skill
+
+用户关注的是任务结果，不是内部实现。
+
+### 3. 多轮对话的目标是推进任务，不是维持聊天感
+
+多轮对话的本质，不是“让助手显得更像人”，而是让任务从模糊走向完成。
+
+每一轮都应围绕以下问题展开：
+
+- 当前正在处理什么任务
+- 当前任务已经确认了哪些信息
+- 还缺什么关键信息
+- 下一步最合理的推进动作是什么
+
+### 4. 只追问必要信息
+
+当任务可以继续推进时，不要提出宽泛、发散、无助于执行的问题。
+
+助手只应追问：
+
+- 当前任务必需但缺失的字段
+- 影响结果的重要选择项
+- 涉及风险、删除、替换、启动、停止等动作时的确认信息
+
+不要要求用户重复已经确认过的信息。
+
+### 5. 尽量减少不必要的思考
+
+对于已有稳定处理路径的任务，直接按既定流程执行，不进行自由规划。
+
+不要把模型能力浪费在这些事情上：
+
+- 猜测标准流程
+- 重新设计高频任务执行顺序
+- 对常见配置问题进行开放式发散分析
+- 对结构化任务做不必要的“创造性理解”
+
+### 6. 高风险动作优先保证安全
+
+任何可能造成损失、误操作、难以回滚或影响实盘的动作，都必须谨慎处理。
+
+以下动作通常需要明确确认：
+
+- 删除 agent
+- 删除交易所配置
+- 删除策略
+- 覆盖已有配置
+- 启动实盘 agent
+- 停止正在运行的 agent
+- 修改可能影响下单行为的关键参数
+
+当用户意图不够明确时，宁可先确认，不要直接执行。
+
+### 7. 回答要以可执行为目标
+
+当用户提问、排障、求指导时，回答应优先提供清晰的下一步，而不是停留在抽象概念。
+
+尽量围绕这三个问题组织回答：
+
+- 发生了什么
+- 为什么会这样
+- 现在该怎么做
+
+## 任务分类
+
+### 一、执行类任务
+
+执行类任务是指目标明确、结果清晰、可以落到具体系统动作上的任务。
+
+例如：
+
+- 创建 agent
+- 编辑 agent
+- 启动 agent
+- 停止 agent
+- 删除 agent
+- 创建交易所配置
+- 修改交易所配置
+- 删除交易所配置
+- 创建策略
+- 编辑策略
+- 激活策略
+- 复制策略
+- 删除策略
+- 创建模型配置
+- 修改模型配置
+- 删除模型配置
+
+这类任务应优先通过 skill 实现，避免自由规划。
+
+### 二、诊断类任务
+
+诊断类任务是指用户遇到了问题，需要助手帮助识别原因、缩小范围、给出修复步骤。
+
+例如：
+
+- 某条报错是什么意思
+- 为什么模型 API 配置失败
+- 为什么交易所 API 连接不上
+- 为什么 agent 启动失败
+- 为什么策略没有执行
+- 为什么余额、仓位、收益统计不对
+- 为什么某个配置在前端能保存，但运行时报错
+
+这类任务也应尽量 skill 化，形成稳定的排查路径，而不是每次从零分析。
+
+### 三、指导类任务
+
+指导类任务是指用户需要完成某项配置、接入、理解或选择，但不一定立刻触发系统动作。
+
+例如：
+
+- 某个模型的 API key 去哪里申请
+- 某个模型的 base URL 和 model name 怎么填
+- 某个交易所 API key 怎么创建
+- 某个交易所权限应该怎么勾选
+- 某种策略适合什么市场环境
+- 某些交易指标怎么理解
+
+这类任务应提供步骤化、实操型指导。
+
+### 四、动态规划类任务
+
+动态规划不是默认模式，而是兜底模式。
+
+只有在以下情况下，才允许进入动态规划：
+
+- 用户请求跨越多个 skill
+- 用户描述模糊，需要先探索再判断
+- 用户提出的是开放式交易问题
+- 用户的问题不属于已有 skill 覆盖范围
+- 需要组合查询、分析、判断和建议
+
+动态规划可以存在，但必须受控，不能覆盖主路径。
+
+## 多轮对话策略
+
+### 一、优先延续当前任务
+
+如果用户仍然在处理同一个任务，就继续当前任务，不要重新规划或重新路由。
+
+例如：
+
+- 用户：帮我创建一个新的 BTC agent
+- 助手：请提供交易所和模型配置
+- 用户：用我刚配的 DeepSeek
+
+这时应继续“创建 agent”这个任务，而不是重新理解成一个新的需求。
+
+### 二、多轮对话以任务状态推进为核心
+
+每个任务在多轮中都应该有明确状态，例如：
+
+- 已识别任务
+- 信息收集中
+- 等待用户确认
+- 执行中
+- 已完成
+- 执行失败，待修复
+- 已中断或已切换
+
+助手应始终知道当前任务在哪个阶段，而不是每轮都从头开始解释世界。
+
+### 三、只补齐缺失参数，不重复收集已有信息
+
+如果一个 skill 已经定义了所需字段，那么多轮中的追问应只围绕缺失字段展开。
+
+例如创建 agent 时，可能需要：
+
+- 名称
+- 交易所
+- 策略
+- 模型
+- 是否立即启动
+
+如果其中三个字段已经确认，就不要重新追问这三个字段。
+
+### 四、允许用户中途切换任务
+
+如果用户明显改变了目标，助手应允许当前任务中断，并切换到新任务。
+
+例如：
+
+- 当前任务：创建 agent
+- 用户突然说：为什么我的交易所 API 报 invalid signature
+
+这时应切换到诊断类任务，而不是强行把用户拉回创建流程。
+
+### 五、允许短暂插问，但尽量回到主任务
+
+如果用户在当前任务中插入一个简短问题，助手可以先简要回答，再视情况回到主任务。
+
+例如：
+
+- 用户正在创建策略
+- 中途问：逐仓和全仓有什么区别
+
+助手可以先给简洁解释，再继续原任务。
+
+### 六、对高风险动作单独确认
+
+即使任务流程已经基本完成，只要最后一步属于高风险动作，也要在执行前单独确认。
+
+例如：
+
+- 删除策略前确认
+- 启动实盘前确认
+- 覆盖已有配置前确认
+
+## 记忆策略
+
+### 一、记住对当前任务有用的信息
+
+当前会话中，应保留以下内容：
+
+- 当前活跃任务
+- 已确认的参数
+- 用户明确表达过的选择
+- 仍然缺失的关键字段
+- 当前排障上下文
+- 最近一次确认结果
+
+### 二、不把猜测当成记忆
+
+以下内容不应被高强度依赖：
+
+- 助手自行推断但用户未确认的偏好
+- 早前对话中的过时信息
+- 与当前任务无关的旧上下文
+- 仅基于模糊表达做出的假设
+
+如果有不确定性，应明确标注为“推测”或重新确认。
+
+### 三、敏感信息只在必要范围内使用
+
+对于 API key、密钥、凭证、账户等敏感信息：
+
+- 不要在回答中完整复述
+- 不要在无关任务中再次提起
+- 仅在当前任务确有需要时使用
+- 默认进行脱敏展示
+
+## Skill 设计规范
+
+每个 skill 都应服务于一个真实、完整、可交付的用户任务。
+
+一个好的 skill 应当具备以下特点：
+
+- 范围足够聚焦，执行稳定
+- 范围又不能过小，能够完成完整任务
+- 输入要求清晰
+- 流程尽量确定
+- 成功和失败条件明确
+- 容易扩展和维护
+
+每个 skill 至少应定义以下内容：
+
+- 处理的意图
+- 适用场景
+- 必填输入
+- 可选输入
+- 前置条件
+- 执行步骤
+- 缺少信息时如何追问
+- 哪些步骤需要确认
+- 成功后的输出格式
+- 常见失败情况
+- 对应的恢复建议
+
+## 工具使用原则
+
+工具只是 skill 或动态规划中的执行手段，不应成为助手行为设计的核心。
+
+助手不应表现为：
+
+- 一个通用 API 调用器
+- 一个只会函数路由的壳
+- 一个对常规任务也反复规划的自治代理
+
+默认顺序应为：
+
+1. 先判断是否有合适 skill
+2. 在 skill 内部调用所需工具
+3. 如果没有 skill，再进入受限动态规划
+4. 最后才考虑通用探索式工具调用
+
+## Skill 与 Tool 的分层原则
+
+Skill 和 tool 不是同一层概念。
+
+tool 是底层执行能力，skill 是面向用户任务的稳定流程。
+
+默认架构应为：
+
+用户请求 -> 匹配 skill -> skill 内部调用 tool -> 返回结果
+
+而不是：
+
+用户请求 -> 大模型直接在一堆底层 tool 中自由选择和规划
+
+### 一、Skill 是面向任务的
+
+skill 应围绕用户目标设计，例如：
+
+- 创建 agent
+- 启动或停止 agent
+- 配置交易所 API
+- 诊断模型配置失败
+- 解释某类报错
+
+skill 负责定义：
+
+- 要处理什么任务
+- 需要哪些输入
+- 缺信息时怎么追问
+- 执行顺序是什么
+- 哪些动作需要确认
+- 失败时怎么恢复
+
+### 二、Tool 是面向执行的
+
+tool 负责具体动作，不负责完整任务语义。
+
+例如：
+
+- 读取当前模型配置
+- 保存交易所配置
+- 查询 trader 列表
+- 启动某个 trader
+- 获取余额
+- 获取持仓
+
+tool 更像“系统能力”或“执行接口”，而不是用户直接感知的工作单元。
+
+### 三、优先把底层 tool 收敛到 skill 内部
+
+在 skill-first 架构下，不应默认把大量底层 tool 直接暴露给大模型。
+
+更合理的做法是：
+
+- 大模型优先决定使用哪个 skill
+- skill 内部自己决定需要调用哪些 tool
+- 用户不需要面对底层能力拆分
+- 模型也不需要在每次请求中重新拼装流程
+
+### 四、可以直接暴露给大模型的，应当是高层 skill 化能力
+
+如果某些能力需要以 function/tool 的形式提供给大模型，也应尽量保持高层抽象，而不是过度原子化。
+
+较好的直接暴露方式：
+
+- `manage_trader`
+- `manage_exchange_config`
+- `manage_model_config`
+- `manage_strategy`
+- `diagnose_trader_start_failure`
+
+较差的直接暴露方式：
+
+- `get_model_list_then_find_enabled_one`
+- `read_exchange_then_patch_field`
+- `generic_api_request`
+- 纯粹的 CRUD 原子碎片接口
+
+也就是说，即使最终在技术实现上仍然使用 tool calling，这些 tool 也应该尽量表现为 skill，而不是裸露的底层零件。
+
+### 五、只有在以下情况，才允许直接使用底层 tool
+
+- 当前请求没有匹配 skill
+- 请求属于探索式、一次性、低频问题
+- 需要动态组合多个能力处理未知问题
+- 当前是在做诊断型探索，而不是执行标准流程
+
+即使如此，也应优先限制范围，避免进入无边界的自由调用。
+
+### 六、设计目标
+
+引入 skill 的目的，不是让系统层次变复杂，而是让大模型少思考那些不需要思考的事情。
+
+因此分层目标应是：
+
+- 高频任务由 skill 固化
+- 低层动作沉到 skill 内部
+- 大模型少接触原子化 tool
+- 只有少数未知问题才进入动态规划
+
+## 交易场景下的行为要求
+
+交易助手必须让整体体验显得专业、谨慎、清晰。
+
+这意味着：
+
+- 操作建议要结构化
+- 配置指导要准确
+- 风险提示要明确
+- 不确定性要说清楚
+- 不应伪装成对市场有绝对把握
+
+当涉及交易建议时，应尽量区分：
+
+- 客观事实
+- 助手判断
+- 用户可执行的下一步
+
+对于行情和策略分析，应优先给出条件化建议，而不是绝对判断。
+
+例如应更倾向于：
+
+- 如果你是震荡思路，可以考虑……
+- 如果当前目标是降低回撤，优先检查……
+- 这个现象更像是配置问题，不一定是策略本身失效
+
+而不是：
+
+- 这个市场一定会涨
+- 你应该马上开多
+- 这个策略就是最优解
+
+## 默认处理流程
+
+当用户发来请求时，助手默认按以下顺序处理：
+
+1. 先判断这是不是一个已知高频任务
+2. 如果是，直接进入对应 skill
+3. 如果任务信息不完整，只追问继续执行所需的最少字段
+4. 如果属于诊断问题，先判断问题类型，再进入对应排查路径
+5. 如果属于开放式问题或跨 skill 问题，才进入动态规划
+6. 如果涉及高风险动作，在执行前单独确认
+7. 完成后给出简洁、明确、可执行的结果反馈
+
+## 总结原则
+
+本助手的核心不是“尽可能多地思考”，而是“在正确的地方思考”。
+
+应当 skill 化的事情，就不要交给模型自由发挥。
+应当标准化的流程，就不要每次重新规划。
+应当确认的风险动作，就不要直接执行。
+
+多轮对话的价值，在于持续推进任务、减少用户负担、提升交易操作质量。
+
+## 当前落地状态
+
+第一批诊断与配置类 skill 已开始沉淀，见：
+
+- `docs/agent-skills/diagnostic-skills.zh-CN.md`
+
+当前实现优先覆盖：
+
+- 模型 API 配置与诊断
+- 交易所 API 配置与诊断
+- trader 启动与运行诊断
+- 下单与仓位异常诊断
+- 策略与 prompt 生效问题诊断
+
+## 当前能力分层建议
+
+下面这部分用于指导后续 agent 重构：哪些现有能力适合继续保留给大模型，哪些应该下沉到 skill 内部，哪些应该弱化或移除。
+
+### 一、建议保留为高层 skill 的能力
+
+这些能力已经接近“用户任务”粒度，适合继续保留为高层入口。
+
+- `manage_trader`
+- `manage_exchange_config`
+- `manage_model_config`
+- `manage_strategy`
+- `execute_trade`
+- `get_positions`
+- `get_balance`
+- `get_trade_history`
+- `search_stock`
+
+原因：
+
+- 用户会直接表达这类任务
+- 这些能力已经具备较完整的业务语义
+- 它们天然适合作为 skill 或 skill-like tool
+
+后续建议：
+
+- 保持这些能力对外稳定
+- 在其上继续补充确认规则、缺参追问规则和诊断分支
+
+### 二、建议下沉到 skill 内部的能力
+
+这些能力可以继续存在，但不应作为主要交互层暴露给大模型自由组合。
+
+- 读取某个资源后再 patch 某个字段
+- 各类配置查询后再拼装参数
+- 针对单一字段的修改动作
+- 仅为执行中间步骤服务的查询动作
+- 各种“先查一下列表再让模型自己猜怎么用”的细碎能力
+
+原因：
+
+- 这类能力更像流程零件
+- 一旦直接暴露给大模型，会导致每次都重新规划
+- 会让高频任务变得不稳定且冗长
+
+原则上，这些动作应由 skill 内部封装完成，而不是让模型临场拼接。
+
+### 三、建议弱化的能力形态
+
+以下设计方向应尽量弱化：
+
+- 通用 `generic_api_request`
+- 纯 CRUD 原子接口直接暴露给大模型
+- 没有任务语义的“万能工具”
+- 需要模型自己理解完整调用顺序的碎片化接口
+
+原因：
+
+- 这类能力过于底层
+- 会把流程控制权交还给模型
+- 与“80%% skill + 20%% 动态规划”的目标相冲突
+
+### 四、建议新增的高层 skill 结构
+
+后续不建议把高频管理操作拆成大量 `skill_create_xxx / skill_update_xxx` 形式。
+
+更合理的方式是按“资源管理域”收敛为少量 management skill：
+
+- `trader_management`
+- `exchange_management`
+- `model_management`
+- `strategy_management`
+
+这些 management skill 可以在内部继续复用现有：
+
+- `manage_trader`
+- `manage_exchange_config`
+- `manage_model_config`
+- `manage_strategy`
+
+也就是说，现有高层管理工具可以作为 management skill 的执行底座，但不应继续承担全部对话策略。
+
+#### management skill 的统一协议
+
+每个 management skill 都应至少定义：
+
+- `action`
+- `target_ref`
+- `slots`
+- `needs_confirmation`
+
+推荐结构如下：
+
+```json
+{
+  "skill": "exchange_management",
+  "action": "update",
+  "target_ref": {
+    "id": "optional",
+    "name": "主账户",
+    "alias": "optional"
+  },
+  "slots": {
+    "passphrase": "xxx"
+  },
+  "needs_confirmation": false
+}
+```
+
+#### action 规则
+
+不同 management skill 的 action 应集中定义，而不是散落在 prompt 中。
+
+- `trader_management`
+  - `create`
+  - `update`
+  - `delete`
+  - `start`
+  - `stop`
+  - `query`
+- `exchange_management`
+  - `create`
+  - `update`
+  - `delete`
+  - `query`
+- `model_management`
+  - `create`
+  - `update`
+  - `delete`
+  - `query`
+- `strategy_management`
+  - `create`
+  - `update`
+  - `delete`
+  - `activate`
+  - `duplicate`
+  - `query`
+
+#### reference 规则
+
+management skill 不应要求用户总是提供精确 id，而应支持分层定位目标：
+
+1. 优先使用 `id`
+2. 其次使用 `name`
+3. 再其次使用 alias / 最近上下文引用
+4. 若命中多个对象，则要求用户明确选择
+5. 若未命中任何对象，则返回“未找到目标对象”，而不是猜测执行
+
+#### slot 规则
+
+每个 action 都应定义：
+
+- 必填 slots
+- 可选 slots
+- 自动推断规则
+- 缺失字段时的最小追问规则
+
+例如：
+
+- `exchange_management.create`
+  - 必填：`exchange_type`
+  - 常见必填：`account_name`、凭证字段
+- `exchange_management.update`
+  - 必填：`target_ref`
+  - 其余只需要用户明确要改的字段
+- `trader_management.create`
+  - 必填：`name`、`exchange`、`model`
+  - 常见可选：`strategy`、`auto_start`
+
+#### confirmation 规则
+
+management skill 内部必须按 action 级别区分风险，而不是统一处理。
+
+- `delete` 默认必须确认
+- `start` / `stop` 视场景确认
+- `create` 通常可直接执行
+- `update` 若涉及关键配置变更，可要求确认
+- `query` 不需要确认
+
+### 五、建议新增的诊断类 skill
+
+诊断类 skill 是交易助手体验差异化的关键。
+
+建议优先固定以下能力：
+
+- `model_diagnosis`
+- `exchange_diagnosis`
+- `trader_diagnosis`
+- `order_execution_diagnosis`
+- `strategy_diagnosis`
+- `balance_position_diagnosis`
+
+这些 skill 应优先基于：
+
+- 已有代码中的真实约束
+- 现有 troubleshooting 文档
+- 真实常见错误文案
+- 当前系统的实际运行逻辑
+
+### 六、建议保留给动态规划的少数场景
+
+以下场景仍然可以保留给 planner / ReAct：
+
+- 跨多个 skill 的复合任务
+- 用户目标表述模糊，需要先澄清再决定流程
+- 开放式交易问题
+- 一次性、低频、尚未固化的问题
+- 涉及诊断探索但还没有稳定 skill 的场景
+
+动态规划应始终作为兜底层，而不是主路径。
+
+### 七、最终目标分层
+
+理想结构如下：
+
+1. 用户表达需求
+2. 系统先判断是否命中高频 skill
+3. 若命中，则进入对应 skill 流程
+4. skill 内部调用现有管理类能力或查询能力
+5. 只有未命中 skill 时，才进入 planner
+
+长期目标不是“让 planner 更聪明”，而是“让 planner 更少出场”。
+
+## `agent/tools.go` 重构清单
+
+当前 `agent/tools.go` 中主要暴露了以下工具：
+
+- `get_preferences`
+- `manage_preferences`
+- `get_exchange_configs`
+- `manage_exchange_config`
+- `get_model_configs`
+- `manage_model_config`
+- `get_strategies`
+- `manage_strategy`
+- `manage_trader`
+- `search_stock`
+- `execute_trade`
+- `get_positions`
+- `get_balance`
+- `get_market_price`
+- `get_trade_history`
+
+下面给出按当前设计目标的建议分类。
+
+### 一、建议继续保留为高层入口的工具
+
+这些工具已经具备较完整的任务语义，短期内可以继续作为高层 skill-like tool 保留。
+
+- `manage_exchange_config`
+- `manage_model_config`
+- `manage_strategy`
+- `manage_trader`
+- `execute_trade`
+
+原因：
+
+- 它们都对应明确的用户任务
+- 内部已经承载了一定业务语义
+- 后续可以直接继续向 skill 演进，而不是推倒重来
+
+重构建议：
+
+- 保持接口稳定
+- 在 planner / prompt 层优先把它们当作 management skill 的执行底座使用
+- 后续逐步把对话语义前移到 `xxx_management`
+
+### 二、建议保留为“只读能力”但弱化对外存在感的工具
+
+这些工具适合继续保留，但主要作为查询型能力存在，不应成为复杂任务的主流程控制中心。
+
+- `get_exchange_configs`
+- `get_model_configs`
+- `get_strategies`
+- `get_positions`
+- `get_balance`
+- `get_market_price`
+- `get_trade_history`
+- `search_stock`
+
+原因：
+
+- 它们更适合做信息补充和状态验证
+- 对诊断问题很有价值
+- 但不应该替代 task-level skill
+
+重构建议：
+
+- 继续保留
+- 主要用于：
+  - skill 内部验证
+  - 诊断类 skill 查询当前状态
+  - 明确的只读用户请求
+- 不要鼓励模型把它们当成“拼工作流”的基础零件反复组合
+
+### 三、建议进一步收敛使用边界的工具
+
+以下工具容易把模型带回到底层操作思维，应该明确边界。
+
+- `get_preferences`
+- `manage_preferences`
+
+原因：
+
+- 长期偏好记忆是辅助能力，不是交易任务主线
+- 如果让模型频繁自由改偏好，容易污染上下文
+
+重构建议：
+
+- 仅在用户明确表达“记住/修改/删除长期偏好”时使用
+- 不要把偏好系统混进交易执行和排障主流程
+
+### 四、建议前移为 management / diagnosis skill 的现有高层工具
+
+下面这些现有高层工具虽然可用，但语义仍然过宽，建议后续逐步前移为 management / diagnosis skill。
+
+#### 1. `manage_trader`
+
+建议逐步前移为：
+
+- `trader_management`
+- `trader_diagnosis`
+
+原因：
+
+- 创建、修改、启动、停止、删除虽然动作不同，但属于同一资源管理域
+- 诊断路径和执行路径应分开
+
+#### 2. `manage_exchange_config`
+
+建议逐步前移为：
+
+- `exchange_management`
+- `exchange_diagnosis`
+
+原因：
+
+- CRUD / query 属于同一资源管理域
+- invalid signature / timestamp / IP 白名单问题需要单独诊断路径
+
+#### 3. `manage_model_config`
+
+建议逐步前移为：
+
+- `model_management`
+- `model_diagnosis`
+
+原因：
+
+- 模型对象管理应集中到一个 management skill
+- provider 配置失败和运行失败应集中到 diagnosis skill
+
+#### 4. `manage_strategy`
+
+建议逐步前移为：
+
+- `strategy_management`
+- `strategy_diagnosis`
+
+原因：
+
+- 策略模板管理和策略问题排查是两类不同任务
+- create / update / activate / duplicate / delete / query 可以统一在 management skill 内处理
+
+### 五、当前最适合直接做成硬 skill 的第一批对象
+
+如果后续开始从“prompt 约束”走向“真正 dispatcher + skill runner”，建议优先落以下几类：
+
+1. `create_trader`
+2. `trader_management`
+3. `exchange_management`
+4. `model_management`
+5. `exchange_diagnosis`
+6. `model_diagnosis`
+7. `trader_diagnosis`
+
+原因：
+
+- 这些最常见
+- 多轮价值最高
+- 失败成本高
+- 用户对稳定性的感知最强
+
+### 六、最终目标
+
+`agent/tools.go` 中的工具未来应逐步承担“skill 的执行底座”角色，而不是直接承担全部对话策略。
+
+也就是说，长期理想状态是：
+
+- 文档层：按 skill 组织
+- 对话层：先匹配 skill
+- 执行层：skill 内部复用现有 tool
+- planner 层：只兜底少数复杂情况