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