make-plan

name	make_plan
description	当需要向更强 Agent 请求执行计划时使用；用于获取分步骤、可落地的计划，并由你自己执行，而不是让对方代执行任务。
metadata	{"builtin_skill_version":"1.3","qwenpaw":{"emoji":"🗺️"}}

制定计划

当你需要向更强 Agent 发起一次外部计划请求时，使用本 Skill。

本 Skill 的目标不是把任务外包出去，而是：

• 向更强 Agent 要一份计划
• 这份计划必须是明确的执行步骤
• 由你自己按计划执行
• 不要求被求助的 Agent 直接动手执行任务

调用步骤：

1. 使用 list_agents() 查可用 Agent 的 ID

• 可根据返回的描述信息选择最合适的 Agent 来求助
• 如果找不到非常合适的 Agent，就选择 default
• 注意区分 Agent 的 ID 和 Name，后续调用需要的是 ID

2. 使用 chat_with_agent(...) 向更强 Agent 请求“制定计划”

• to_agent 传目标 Agent ID
• text 中明确给出提示仅需给出可按步骤执行的计划，不要执行

3. 收到回复后，记录对话的 session_id，并提炼出真正可执行的步骤，并由你自己执行

• 如果有不清楚的地方可以继续追问细化计划，但仍然要强调只补计划，不要代执行
• 追问仍使用 chat_with_agent(...)，并传入记录的 session_id 以保持上下文

推荐调用骨架：

list_agents()

chat_with_agent(
  to_agent="stronger_agent",
  text="[Agent <auto> requesting] 请帮我为下面任务制定执行计划。你不需要执行任务，只需要输出明确、可落地、按顺序排列的步骤。",
)

适用场景

以下场景适合直接发起外部计划请求：

• 任务需要多步拆解
• 步骤之间有依赖关系
• 需要明确先后顺序、检查点或验证点
• 涉及多个模块、文件、系统或角色
• 用户明确要求先给出计划
• 你希望先拿到一份更完整、更稳妥的执行路径

不要这样用

以下情况不要用本 Skill：

• 你其实是想让对方直接替你做任务
• 真正缺的是一个小事实，而不是计划
• 真正需要的是架构判断或方案比较
• 你连任务目标都没理解清楚

向更强 Agent 要什么

调用 chat_with_agent(...) 时要明确说明：

• 你需要的是计划，不是代执行
• 步骤必须具体，不能只给抽象建议
• 最好包含验证方式与完成标志

求助模板

请帮我为下面任务制定一份执行计划。 你不需要执行任务本身，只需要输出计划。

任务： [要做什么]

目标： [最终想达到什么结果]

约束：

• [...]
• [...]

计划要求：

1. 拆成明确、可执行的步骤
2. 标明推荐顺序
3. 必要时指出依赖、检查点或验证方式
4. 如果有明显风险，补充关键注意点

输出格式： [例如：输出 5-8 个编号步骤，每步 1-3 句]

chat_with_agent 请求示例：

chat_with_agent(
  to_agent="strong_agent",
  text="""
请帮我为下面任务制定一份执行计划。
你不需要执行任务本身，只需要输出计划。

任务：
修改一个多模块功能。

目标：
以较低风险完成改动，并避免遗漏联动点。

约束：
- 尽量减少返工
- 需要保留可验证的中间检查点

计划要求：
1. 拆成可落地的步骤
2. 标明推荐顺序
3. 标出关键依赖和检查点
4. 尽量包含验证方式

输出格式：
请输出 3-5 个编号步骤，每步尽量具体。
""",
)

chat_with_agent 回复示例：

[SESSION: xxx]

下面是我为你制定的执行计划：

1. ...
2. ...

• 其中 xxx 是本次对话的 session_id，你需要记录下来以便后续追问细化，一般是一个较长的字符串，例如 local_agent:to:strong_agent:1776406127168:e11b08d8

chat_with_agent 追问示例（假设你想让对方细化第 3 步）：

chat_with_agent(
  to_agent="strong_agent",
  text="请基于刚才的计划，再细化第 3 步。仍然只需要补计划，不需要代执行任务。",
  session_id="xxx",
)

收到计划后怎么用

把更强 Agent 的回复当作“执行计划输入”，不是“任务已经完成”。

你应该做的是：

1. 提炼出真正可执行的步骤
2. 判断是否需要按你的环境做微调
3. 由你自己执行这些步骤
4. 遇到新不确定性时，再继续细化计划

不要把计划原样当成结果交付给用户，除非用户要的就是计划本身。

计划质量标准

一份合格的计划，至少应满足：

• 有明确步骤，而不是泛泛建议
• 步骤顺序清楚
• 每步是可执行动作
• 关键依赖被点明
• 有必要的验证点
• 没有把“执行任务”偷偷转交给被求助 Agent

如果拿到的是空泛建议，例如“先分析，再实现，再测试”，这不够，需要继续追问细化。

行为护栏

• 不要把“请帮我规划”说成“请你直接做完”
• 不要请求对方代替你执行代码、命令或变更
• 不要接受只有方向、没有步骤的回答
• 不要在目标不清楚时直接求计划
• 不要拿到计划后就停止思考，仍要结合当前环境判断

最终口诀

缺执行路径，就先要计划。 计划必须分步、具体、能落地。 被求助 Agent 负责出计划，不负责代执行。 拿到计划后，由求助发起者自己执行。