Claude Fable 5.1 提示指南:16 条提示词建议 一份 Agent 运行时迁移清单
从发布背景到 16 条官方建议,逐项解释 effort、工具循环、消息历史、长任务交付与视觉处理,并提供可直接改写使用的中英双语提示词。
- Anthropic 发布 Claude Fable 5.1 与 Mythos 5.1;本站已有独立发布解读,本篇聚焦从 Fable 5 迁移到 5.1 时的 Prompt 与 Agent 运行时调整。
- 官方 16 条建议并非 16 句万能 Prompt,而是覆盖思考预算、工具与界面、消息历史、交付约束四个控制面。
- 16 条建议依次覆盖各类症状、原因和修复入口;属于提示词层的建议都可以用中英双语模板直接落地。
- 迁移应先处理接口兼容和 append-only 历史,再评测 effort、打开进度、优化工具循环,最后调整文风、检索、长输出和视觉工具。
Anthropic 发布了最新的 Claude Fable 5.1 和 Claude Mythos 5.1 两款旗舰模型。两者使用同一个底层模型,Fable 5.1 面向一般用户,Mythos 5.1 通过受信任访问计划向部分网络安全与生命科学专业人员开放。Fable 5.1 的升级重点包括编程、知识工作、长时间自主执行,以及更低的缓存读取成本。
站内已有文章
Anthropic 发布 Claude Fable 5.1 与 Mythos 5.1:长时间自主执行能力提升 缓存读取降价 75%
背景:模型升级以后,为什么还需要一份专门的提示指南
Fable 5.1 的变化不只体现在“回答更聪明”。它更擅长长时间执行复杂任务,adaptive thinking 始终开启,并允许开发者用 effort 在质量、延迟和成本之间做选择。与此同时,thinking blocks 的会话绑定更严格,工具循环的可观察性、历史消息的组织方式和长输出的 token 分配也随之变得重要。
这意味着,同一个故障可能发生在完全不同的层面:
- 模型没调用搜索,可能是
loweffort 下的行为倾向; - Agent 长时间没有文字,可能是客户端没有请求或展示 progress updates;
- 多轮请求突然报 400,可能是客户端改写了旧消息,破坏 thinking block 的前缀绑定;
- 主 Agent 等着子 Agent 不再工作,可能是启动子任务的工具本身被设计成阻塞调用;
- 长报告写到一半被截断,可能是 thinking 和正式回答共同耗尽了
max_tokens。
所以,这份指南虽然叫“Prompting”,实际覆盖了模型参数、API 配置、消息协议、Agent 调度、代码编辑和前端呈现。只改 system prompt,解决不了其中一半问题。
指南的核心:先判断症状属于哪一层,再使用对应修复
官方的 16 条建议采用“看到什么现象,就检查对应章节”的组织方式。把它落到产品里,可以归纳为四个控制面:
- 思考预算:不同任务应该选择什么 effort,什么时候升档或降档;
- 工具与界面:如何展示进度、批量调用工具、异步调度子 Agent;
- 消息历史:为什么必须 append-only,如何安全追加临时规则和压缩上下文;
- 交付约束:既要求模型完整做完,又防止它扩大范围、重写整文件或提交过量测试。
先定位故障层,再改 Prompt
high 起步评测;low 关注检索;xhigh/max 关注长输出。
display 决定看不看得到;调度器决定并行是不是真的。
thinking block 绑定此前的 tools、system 与 messages。
原范围内可逆动作继续执行;破坏性或架构分歧才停。
迁移前检查
- 不再使用
tool_choice: "any",也不要强制指定某个工具;- 不要让较早模型读取 Fable 5.1 生成的 thinking blocks;
- 不要编辑会话中已经产生 thinking blocks 的旧消息。
一、先确定思考档位(建议 1)
1. 不要沿用旧模型的 effort 结论,重新测试全部档位
你会看到什么:任务质量不错,但延迟或成本超过需要;或者团队直接把 Fable 5 的 effort 配置照搬到 5.1。
为什么会这样:同样叫 medium 或 high,不同模型实际使用的思考量并不相同。Fable 5.1 的能力提升覆盖各个档位,高档位增益更明显,但不是每个任务都需要高档。
Anthropic 建议从默认的 high 开始,然后用自己的评测依次测试 low、medium、xhigh 和 max。官方观察是:medium 的结果大致可与 Fable 5 相当,成本更低;low 在一些任务上具有很强的单任务成本竞争力,因此也应该和较小模型的高 effort 方案一起比较。
这里不能把结论写成“low 普遍胜过 Opus 和 Sonnet”。官方使用的是 roughly、often 和 competitive 这样的限定语。生产决策必须记录真实任务的成功率、总 token、工具调用轮数、墙钟时间、搜索触发率和返工率。
| 档位 | 适合先测的任务 | 需要额外观察的风险 |
|---|---|---|
low |
分类、抽取、常规子步骤 | 更少主动搜索,容易凭记忆回答 |
medium |
批量工作、质量已经稳定的任务 | 仍需验证复杂边界是否退化 |
high |
复杂编码、研究和多步 Agent;官方推荐起点 | 成本和延迟可能超过简单任务需要 |
xhigh / max |
只有实测出现额外质量收益的难题 | 思考时间长,长成品更容易触及输出上限 |
这条建议主要靠评测和路由实现,不需要给模型增加一段固定 Prompt。
二、修正工具循环(建议 2—3)
2. 让用户看见长工具任务的进度
你会看到什么:Agent 连续调用工具时几分钟不说话,用户以为任务卡死;最终回复又只解释最后一步,没有完整复盘。
为什么会这样:Fable 5.1 会把简短进度放在 progress-update thinking blocks 中,但默认的 thinking.display 是 "omitted",这些 block 的内容会是空的。模型可能已经产生进度,客户端却根本没有请求或展示它。
先修改 API 请求:
{
"thinking": {
"type": "adaptive",
"display": "updates"
},
"betas": [
"thinking-display-updates-2026-08-18"
]
}
客户端应把非空 thinking block 渲染成短状态行。如果需要同时获得经过汇总的 reasoning,可以使用 display: "summarized"。这些内容是面向用户的进度摘要,不是原始思维链,也不是可靠的执行回执;任务是否真正开始和完成,仍应由调度器的 attempt、run ID、工具结果和错误状态证明。
如果产品还需要更稳定的文字进度,或者前端会隐藏命令输出,可以把两项约束放在一起:
English
Before starting, state in one sentence what you are about to do. During longer tasks, give brief updates on what you just found and what you are doing. End with a self-contained recap covering the findings, the work actually completed, and anything still outstanding.
Only you can see the full output of this command; the user interface shows at most a few lines. Put anything the user needs to read in your reply.
中文
开始工作前,用一句话说明你将要做什么。执行较长任务时,用简短更新说明刚刚发现了什么、正在做什么。结束时给出一份可以独立阅读的简要复盘,包括发现、实际完成的工作和仍需处理的事项。
这条命令的完整输出只有你能看到,用户界面最多显示其中几行。凡是用户需要阅读的信息,都必须写进你的回复。
3. 把互不依赖的工具调用放进同一轮
你会看到什么:用户明确要求查 A、B、C 时,模型通常会并行;但在编码或 computer-use 循环中,模型自己推导出来的下一批读取操作,经常一轮只调用一个工具。
为什么会这样:显式并列任务容易识别,隐含在环境探索中的独立请求需要模型先规划。每增加一轮,就会增加一次模型调用、上下文 token 和网络往返时间。
English
First list privately what information you need next. Then request every independent item in this turn, leaving only genuinely dependent requests for a later turn.
中文
先在内部列出下一步需要取得的信息;然后在这一轮中一次性请求所有互不依赖的项目。只有确实依赖前一个结果的请求才留到下一轮。
这条提醒适合在每次返回 tool_result 后重新追加。可使用 turn-scoped system message:
{
"role": "system",
"content": "Batch independent calls.",
"clear_at": "next_user_message"
}
它需要 beta header mid-conversation-system-clear-at-2026-08-21。每轮追加新副本,但不要删除或改写旧副本;后续用户消息出现后,API 会让旧的 turn-scoped 提醒对模型不可见。
三、保护消息历史并控制表达(建议 4—7)
4. 保持消息历史 append-only
你会看到什么:多轮请求报 400 bound to a different conversation;或者开启测试配置后,服务端丢弃了早先的 thinking blocks。
为什么会这样:Fable 5.1 的 thinking block 会绑定生成它时的精确会话前缀,包括顶层 system、工具列表和此前消息。对 2026 年 8 月 31 日 00:00 UTC 及以后创建的新账号,这项校验默认生效。
会话是一条只能向右追加的日志
旧前缀不变 → thinking 仍有效
前缀改变 → 400 或丢弃 block
正确做法是把会话当成只追加日志:assistant 返回什么,就把该轮连同 thinking blocks 原样放回历史;新的用户消息、工具结果和规则继续添加在末尾。不要编辑、重排或删除旧消息,也不要直接替换顶层 system 或已经参与会话的 tools。
需要中途改变规则时,追加 mid-conversation system message;需要临时单轮提醒时,使用带 clear_at: "next_user_message" 的 turn-scoped system message;需要裁剪上下文时,优先使用服务端 compaction 或 context editing。
客户端自定义压缩时,最简单的安全做法是启动一段新历史,只放完整摘要和最新用户指令,不再回放旧 thinking blocks。可以在测试环境把 prefix_mismatch_behavior 设为 "drop_block",再检查 input_transformations,用来找出集成中哪些旧消息被改动。
5. 删除华而不实的 mannered prose
你会看到什么:句子变长、段落密度上升,本来可以直接说明的内容被换成展示写作者姿态的比喻。
为什么会这样:Fable 5.1 的整体写作质量有所提升,但某些任务仍会用修辞替代精确表达。官方称这种反模式为 mannered prose。
English
Remove all mannered prose. When a literal statement is available, use it instead of metaphor, flourish, or language that performs the writer rather than conveying the meaning.
中文
删除所有矫饰性表达。能直接说明时就直接说明,不要用隐喻、漂亮话或写作者姿态替代准确含义。
6. 按信息结构使用排版,不要继续沿用过强的“禁格式”规则
你会看到什么:回复变成密不透风的纯文本,复杂比较没有列表、标题、表格或引号。
为什么会这样:早期模型容易滥用粗体和列表,很多旧 system prompt 因此写了全面禁止格式的规则。Fable 5.1 本身更少主动使用结构化排版,两者叠加就会损害可读性。
English
Use lists, headings, or tables when the content has multiple parallel aspects, steps, or exact comparisons and the structure improves clarity. Use plain paragraphs for ordinary conversation, and follow explicit requests for minimal formatting.
中文
当内容包含多个并列方面、步骤或精确比较时,使用列表、标题或表格提高可读性。普通对话保持自然段;用户明确要求极简格式时,遵从该要求。
7. 用自己的话转述检索结果,只保留少量明确标记的短引语
你会看到什么:模型总结网页时直接沿用来源措辞,却没有加引号,读者无法区分转述与原文。
为什么会这样:单独写一句“不要抄原文”不够具体。官方建议在 system prompt 中给一个完整 few-shot:用户问题、检索动作、合格回答和 <rationale>,让模型看见正确的比较与转述方式。
可使用下面这份缩短后的双语模板,再换成你自己的工具名和业务案例。
English
<example>
<user>Retrieve Source A and Source B on the same event and compare them.</user>
<response>State the facts both sources confirm in your own words, then compare what each emphasizes. Keep at most one necessary short phrase verbatim and mark it with quotation marks; paraphrase everything else.</response>
<rationale>The answer is organized around agreement and difference rather than walking through each article. Source views are reported indirectly, and the only verbatim phrase is clearly marked.</rationale>
</example>
中文
<example>
<user>检索来源 A 和来源 B 对同一事件的报道,并比较两者。</user>
<response>先用自己的话说明两者共同确认的事实,再比较各自强调的角度。只保留一个确有必要的短语原文,并明确加引号;其余内容全部转述。</response>
<rationale>回答按共同点与差异组织,没有逐篇复述;来源观点使用间接引语,唯一的原文短语有明确引号。</rationale>
</example>
四、让长任务完整收口,同时限制范围(建议 8—10)
8. 要求模型完成整个任务,不要停在行动预告
你会看到什么:模型以“接下来我会修改……”结束,却没有真的修改;或者对原请求已经包含的步骤反复询问“需要我继续吗”。
为什么会这样:长任务中的一次 turn 可能被模型误解成阶段汇报。解决办法是明确自主执行边界,同时保留破坏性操作和真实范围变化的停点。
English
You are operating autonomously. The user is not watching in real time and cannot answer repeated confirmations during execution. Proceed with every reversible step already authorized by the request and consistent with its intent. Stop only for destructive actions or genuine scope changes that require the user's decision.
Before ending, inspect your final paragraph. If it is still a plan, a question, a list of next steps, or a promise of unfinished work, keep using tools and complete the in-scope work. End only when the task is complete or blocked on information only the user can provide.
中文
你在自主执行任务。用户不会实时守在电脑前,不能回答执行途中的重复确认。凡是原请求已经授权、符合原意且可逆的步骤,直接执行;只有破坏性操作或必须由用户决定的真实范围变化才停下询问。
结束前检查最后一段:如果它仍是计划、问题、下一步清单,或承诺尚未完成的工作,就继续使用工具把范围内的工作做完。只有任务完成,或确实缺少只有用户才能提供的信息时,才结束本轮。
这条规则应带一个明确例外:当用户只是提问、描述问题或要求诊断时,交付物是分析报告,不代表可以自动实施修复。
9. 告诉上下文压缩器必须保留什么
你会看到什么:长会话压缩后,模型忘记已经否决的方案、用户原话、当前完成边界或精确代码标识符,又从头调查或重复提问。
为什么会这样:“总结一下对话”只要求压短,没有定义哪些信息丢失后会破坏后续执行。服务端 compaction 已经针对这一点优化;自己做客户端摘要时必须给出保存合同。
English
Create a summary that a new context window can use to continue the work. Preserve completely: (1) obstacles and how they were resolved; (2) approaches proposed, tried, or rejected and why; (3) the user's explicit preferences, constraints, decisions, and boundaries, keeping their wording where possible; (4) the exact current state and completed scope; (5) unresolved, promised, or required next work; and (6) hard-to-reconstruct details such as names, numbers, dates, exact wording, links, and code identifiers.
Prefer completeness over brevity for these items. Compress the assistant's explanations and reasoning to their conclusions and produced results.
中文
请生成一份可供新上下文继续执行的摘要。必须完整保留:
1. 已遇到的阻碍及处理结果;
2. 提出、尝试或否决过的方案及原因;
3. 用户明确提出或确定的偏好、限制、决定与边界,尽量保留原话;
4. 当前具体进展和已经完成的范围;
5. 仍未解决、已经承诺或下一步必须处理的事项;
6. 难以重建的精确细节,包括名称、数值、日期、原句、链接和代码标识符。
上述内容宁可写长也不要遗漏;助手自己的解释和推理只保留最终结论与产出。
10. 只实现请求要求的功能,并控制永久测试数量
你会看到什么:开放式编码任务完成了目标,却顺手重构邻近文件、修旧 Bug、扩展未要求的行为,并提交许多只为临时排错写的测试。
为什么会这样:“完整完成”如果没有范围约束,容易被解释成把所有相关问题一起解决。官方测试表明,明确限制额外工作,可以显著减少无关修改,而不会降低请求本身的成功率。
English
Implement only the behavior explicitly required by this task. If you find an unrelated pre-existing bug, performance concern, cleanup opportunity, or extension, do not change it here; report it as a follow-up. Use the interpretation most directly supported by the request and surrounding code instead of implementing every possible reading.
Use scratch scripts and quick checks as needed, but do not automatically commit them as permanent tests. Add focused tests only when the task asks for them or the repository already keeps tests for this kind of change, sized like neighboring tests. Implement every requested behavior completely.
中文
只实现本任务明确要求的行为。如果发现与本任务无关的旧 Bug、性能问题、清理机会或功能扩展,不要在本次修改中处理;在最终总结中列为后续建议。采用最符合请求文字和现有代码的解释,不要同时为其他可能解释也构建一套实现。
可以使用临时脚本和快速检查验证工作,但不要自动把它们提交为永久测试。只有任务明确要求,或仓库已经为同类改动保留测试时,才按相邻测试文件的规模增加聚焦测试。必须完整实现请求中的全部行为。
五、提高检索、编辑与长输出的可靠性(建议 11—14)
11. 在 low effort 下明确触发搜索
你会看到什么:模型认识一个名称,就直接凭记忆回答;但名称来自快速变化的 AI 模型、开发工具或当前事件,答案已经过时。
为什么会这样:Fable 5.1 在 low effort 下比 Fable 5 更少调用搜索和检索工具。有时只把受影响的 turn 升到更高 effort 就能解决;也可以明确规定哪些信息必须验证。
English
When a query centers on a name you do not confidently recognize, or on a fast-moving area such as AI models, developer tools, prices, or current status, search before answering. Include the name exactly as the user wrote it in at least one query. Partial familiarity is not a reason to skip verification.
中文
当问题围绕你不能确信认识的名称,或来自数月内就可能变化的领域,例如 AI 模型、开发工具、价格和当前状态时,先检索再回答。至少一次搜索必须包含用户输入的名称原文。对名称有部分印象不是跳过搜索的理由。
12. 通过请求措辞和工具输出减少安全误伤
你会看到什么:允许的代码检查返回 stop_reason: "refusal"。
为什么会这样:Fable 5.1 的安全分类器仍可能被某些提问方式、缺少语法背景的冷门语言,以及工具直接写入上下文的 Base64 数据触发。
官方给出的典型改写是:
English
Avoid: Does this program compile and run without errors?
Prefer: Are there any bugs in this program? Identify their locations and causes.
中文
不推荐:这段程序能否无错误地编译运行?
推荐:这段程序是否存在 Bug?请指出位置和原因。
对冷门语言,应给模型该语言的官方语法或文档背景。工具输出中的原始 Base64 应从模型上下文移除,改成文件引用、MIME 类型、尺寸、哈希或其他受控元数据;仅在外层增加标签并不能解决问题。客户端还必须解析 stop_reason,不能把 HTTP 200 当成任务成功。
13. 小改动优先局部编辑,不要重写整份文件
你会看到什么:只改几十行,模型却重新输出上千行文件,导致输出 token、耗时和冲突风险一起增加。
为什么会这样:Fable 5.1 比 Fable 5 更倾向于对文本文件进行整文件重写,即使最终内容基本相同。
English
Minimize the tokens used to edit files when doing so does not affect the result. Prefer surgical, targeted edits for small changes. Rewrite the whole file only when it is short or most of its contents must change.
中文
在不影响最终结果的前提下,尽量减少编辑文件所需的 token。小范围改动优先采用外科手术式的局部修改;只有文件很短或大部分内容都需要变化时,才重写整份文件。
14. 为 xhigh 和 max 的长输出预留完整 token 空间
你会看到什么:模型在正式回答前等待很久,最终长报告、代码文件或大表格又被 max_tokens 截断。
为什么会这样:在 xhigh,尤其是 max,模型可能先在 thinking 中起草大量成品,再在正式回复中重新写一遍。thinking 和 reply 共同占用一次响应的输出上限。
首选办法是让长成品从 high 开始,只有评测证明升档能提高质量时才使用 xhigh/max。确实需要高档位时,设置足够的 max_tokens,并在用户消息末尾加入下面的边界。
English
Reasoning, drafting, and the final reply all count toward a total limit of about [max_tokens] tokens in this turn. Use reasoning to analyze inputs, verify dependencies, settle the structure, and resolve difficult decisions. Write the complete article, code, or table only once in the final reply. Do not draft the full deliverable in reasoning and then repeat it in the answer.
中文
本轮 reasoning、草稿和最终回复共同计入约 [max_tokens] token 的总上限。请在 reasoning 中分析输入、核对依据、确定结构并解决困难决策;完整文章、代码或表格只在最终回复中写一次。不要先在 reasoning 中全文起草,再在回复中重复一遍。
六、让子 Agent 真正并行,并为视觉任务提供放大工具(建议 15—16)
15. 子 Agent 运行时,主 Agent 不要被启动工具阻塞
你会看到什么:主 Agent 分配了子任务,却停在那里等结果,所谓并行并没有缩短完成时间。
为什么会这样:如果“启动子 Agent”的工具调用一直挂起,直到子任务完成才返回,那么模型没有机会继续处理其他工作。Prompt 中写“并行执行”也改变不了阻塞的工具接口。
正确的调度方式包含三部分:
- 启动子 Agent 的工具立即返回任务句柄;
- 主 Agent 继续完成所有不依赖该结果的工作;
- 子 Agent 完成后,通过后续 user message 把结果注入主 Agent;另提供一个只有确实需要时才调用的等待工具。
官方观察是:模型有时仍会主动选择等待,但只要启动接口非阻塞,那些继续工作的运行就能获得真实的墙钟时间收益,平均质量、token 和成本基本相近。
16. 密集图表和细节图需要 crop-and-zoom 工具回路
你会看到什么:模型能理解图片大意,却读错密集图表的小字、坐标、图例或局部关系。
为什么会这样:把整张高密度图压进一次视觉输入,会让有限的视觉 token 同时承担全局布局和局部细节。Fable 5.1 更适合迭代观察:先看全景,判断需要核对的区域,再裁剪、放大、复读,最后回到全图确认位置关系。
完整方案是给视觉 Agent 一个容器,提供原始图像以及 PIL、OpenCV 等基础图像处理库。成本更低的方案是只提供 crop 工具:模型提交坐标,工具返回放大后的局部区域。关键在于让模型根据第一次观察,自主决定第二次应该查看哪个区域。
把 16 条建议落地:一份按风险排序的迁移清单
如果直接把所有双语 Prompt 拼进 system prompt,规则会很长,也很难知道是哪一条产生了效果。更稳妥的迁移顺序如下:
- 先检查接口兼容性:移除强制
tool_choice,验证 thinking block 的读取方向和 fallback。 - 再检查消息前缀:连续记录几轮真实请求,确认旧
system、tools和历史消息没有被编辑。 - 建立 effort 评测:按任务族比较成功率、成本、延迟、搜索触发和返工率。
- 修复可观察性:打开 progress updates,同时用调度器状态证明任务是否真正执行。
- 优化工具循环:添加批处理提醒,把子 Agent 启动接口改成非阻塞。
- 成对设置交付规则:一边要求做完整,一边限制范围、测试和整文件重写。
- 最后处理输出质量:再加入文风、格式、引用、低档搜索、长输出和视觉裁剪规则。
最终评测不要只看回答是否“更像 5.1”。应该比较同一任务是否更少失败、更少空等、更少无效工具轮次;历史压缩后是否仍能继续;长成品是否完整;模型是否做完了全部授权范围,同时没有修改范围外的东西。
这就是这份指南的核心:Fable 5.1 的 Prompt 依然重要,但 Prompt 已经只是 Agent 运行时的一部分。先修接口与消息协议,再用针对具体症状的提示词做最后一层校正,才能真正得到稳定、可解释、可评测的迁移结果。
Fable 5.1 迁移控制台
16 条建议不该堆进一条 system prompt。先判断故障属于思考预算、工具接口、消息历史还是交付约束,再改对应层。
先定位:问题属于哪一层
迁移闸门:先过三项接口检查
- 01移除 tool_choice: "any",也不要强制指定某个工具。
- 02不要让旧模型读取 Fable 5.1 生成的 thinking blocks。
- 03不要编辑已参与 thinking block 绑定的旧消息、system 或 tools。
Effort 不是排名,是路由参数
Agent 循环:可见、批量、异步、只追加
- 进度可见启用 thinking display updates,并在开始、中途、结束提供短更新与完整复盘。
- 调用批量每轮先梳理所需信息,把互不依赖的读取和请求一次发出。
- 子任务异步启动工具立即返回;主 Agent 继续非依赖工作,完成结果再异步注入。
- 历史只追加不改旧消息;临时规则用 mid-conversation system message 追加。
落地顺序:先修运行时,再调表达
- 1 接口tool_choice、thinking 读取方向、fallback。
- 2 历史prefix 绑定、append-only、压缩与临时规则。
- 3 评测按任务族比较 effort 的成功率、成本与延迟。
- 4 循环进度显示、批量工具调用、非阻塞子 Agent。
- 5 交付做完但不越界,局部编辑,长输出只写一次。
- 6 视觉密集图表提供裁剪放大工具,允许多轮重读。
Prompt 没坏,运行时先冒烟了
工程师旧 Prompt 能跑,那就直接切模型。
兼容的是多数 Prompt,不是所有参数、历史和调度器。
工程师它到底没搜索,还是已经卡死了?
不搜索和不显示进度是两类问题:一个在行为与路由,一个在接口与前端。
主 Agent启动工具不返回,我就没有下一轮去做其他工作。
Prompt 无法把阻塞接口变成异步,也无法修复被改写的会话前缀。
工程师先定位是哪一层,再决定改参数、接口、调度器还是提示词。
16 条建议是一张故障地图,不是一条巨型 system prompt。
主 Agent我先继续所有不依赖子任务结果的工作。
真正的并行来自非阻塞接口;真正的连续性来自 append-only 历史。
Agent范围内的工作已完成;遗留问题只报告,不顺手改。
先修接口和历史,再调 effort 与工具循环,最后约束表达和交付。
