https://jiajia.fun/qa/12ddd469-%E5%B8%AE%E6%88%91%E6%8A%8A-skill-%E6%B8%85%E5%8D%95%E5%92%8C-agent-%E8%BE%B9%E7%95%8C%E5%88%97%E4%B8%80%E7%89%88%E5%87%BA%E6%9D%A5%E5%AF%B9%E7%9D%80%E7%9C%8B-%E5%90%8C%E6%97%B6%E5%B8%AE%E6%88%91%E6%A0%B8%E5%AF%B9%E4%B8%8B%E6%9F%90%E4%BA%9B%E6%A8%A1%E5%9E%8B%E5%92%8C%E6%88%91%E8%AF%B4-%E6%9E%B6%E6%9E%84%E6%9C%AC%E8%BA%AB%E4%B8%80%E6%97%A6%E5%AE%9A%E4%B8%8B-%E4%BB%A5%E5%90%8E%E6%97%A0%E9%9C%80%E9%87%8D%E6%9E%84-%E6%98%AF%E4%B8%8D%E6%98%AF

# 帮我把 skill 清单和 agent 边界列一版出来对着看,同时帮我核对下某些模型和我说,架构本身一旦定下,以后无需重构,是不是

回复 群友 6932： 先回答后半句，因为它是前提：那个说法不成立。 架构定下来以后不用重构，这个说法只在一种情况下成立：你还没跑过真实任务。真实项目里，架构一定会变，变的不是「几个 agent」这种大骨架，而是边界和切面。原因很具体：你只有在真实运行中才会发现「这两个 skill 其实共用同一份上下文」或者「这个 subagent 的输出被下游反复退回来、说明契约没定对」。这些东西看不出来，只能撞出来。 但也不要走到另一个极端，天天重构。比较准的说法是：agent 的骨架（谁是编排者、谁是执行者、谁是审查者）应该尽量稳定，重构的是 skill 内部的流程、参数和它们之间的契约边界。判断信号：如果你在不停改 agent 的职责描述，说明当初按角色切错了维度，该重切；如果 agent 半年没动、一直在改 skill，这是健康的。 下面按你 pa 这套列一版，你可以拿来对着看。 一、Skill 清单（按「一件事能做完整」切，不按「一个概念」切） 1. 策略决策 skill 里面同时包含概率估计、盈亏比计算、仓位定档三件事。必须放一起，因为它们是同一条决策链上的三个参数，单独看任何一项都没意义。输入是某个周期的行情与账户状态，输出是「做不做、做多少、止损止盈在哪」。内部是固定流程加可调参数，长到出现明显分叉（比如不同品种走完全不同的判据）才考虑拆。 2. 行情与周期数据准备 skill 负责取数、对齐时间轴、处理缺失和停牌、把日线小时线分钟线整理成同一套结构。这是纯工程活，最容易写错也最该复用。它被调用多次、传不同周期参数，不是一个周期一个 skill。 3. 风险评估与回测 skill 给定一段历史或一段模拟输出，算出收益、回撤、胜率、盈亏比分布、连续亏损次数，并对照风控上限。它和策略决策分开，因为它是评价者，不能和生成者共用上下文。 4. 复盘与参数调整 skill 基于 3 的输出指出「哪一类行情下这套参数失效」，产出调整建议。注意它只产出建议，不自动改参数。 5. 报告与通知 skill 把一轮结果按固定格式输出，包括写了什么、为什么、数据在哪。这个 skill 的价值是把「结论必须有证据」变成格式强制，而不是靠模型自觉。 暂时不要新增的：情绪判断、宏观解读、新闻事件分析。这些在你还没跑通主链路之前，属于给自己加噪音。 二、Agent 边界（只列必须有独立上下文的） 1. 编排者（主 agent） 接用户指令，拆成「跑哪些周期、用什么参数、跑多久」，派活，收集结果，判断这轮算不算完成。它不碰策略细节和行情数据，上下文保持干净。它自己不做策略计算，也不写报告。 2. 执行者（worker subagent，可多个并行） 一个 worker 负责一个周期或一个参数组合的一次完整流程：调数据准备 skill、调策略决策 skill、输出这一轮的结果摘要。独立工作区，只回传摘要和关键数据文件路径，不回传全部中间过程。可以按周期并行开，比如日线、60 分钟、15 分钟各一个。 3. 审查者（复盘 agent） 唯一必须严格独立上下文的：它不参与生成，只看 worker 交上来的结果和回测数据，判断有没有越风控边界、参数是否在合理区间、结论有没有数据支撑、有没有明显的过拟合迹象。发现不合格打回，附具体理由。它和 1、2 必须是不同的会话，否则就是自己给自己打分。 就这三个。判断某个东西要不要升成 agent，只问三条：需不需要独立审查、是不是耗时长且可并行、上下文装不装得下。三条都不满足，就写成 skill 或者主 agent 的一个步骤。 三、Skill 和 Agent 之间的契约，这层比清单更重要 每个 skill 的输入输出必须落成文件或明确结构，不能靠对话传递。worker 交给审查者的应该是一份结果文件，里面固定有：跑了哪些周期、每轮决策及依据、关键指标、异常记录。审查者只看这份文件加原始数据，不看对话历史。 这层契约是唯一值得一开始就设计好的东西。它定错了，你会反复返工；它定对了，skill 内部怎么改、agent 换成几个都能接得上。这也回到你前半句：架构不用重构的前提，不是骨架定死，而是契约稳定。 四、什么时候该动架构 给三个触发条件，比「该不该重构」这种主观判断好用： 同一个 skill 改到第三处开始要加条件分支了，拆。 连续两次因为 agent 职责不清导致返工，重划边界。 某个 subagent 的输出被审查者反复退回，且理由都指向输入不够，说明契约缺字段，先改契约，别急着拆 agent。 要不要我按这套，帮你把结果文件的具体字段列一版？