由 【拯救 5.6 Sol（1）】开箱即用、快速高效、减少上下文腐烂的Codex子代理实践 受到启发。 背景 1、本人订阅了GLM Max Plan，且Astra额度平常实在不够用 2、GLM 5.3在规划上确有独到之处，我愿称之为国产Claude平替 3、最危险的地方就是最安全的地方，ZCode近期应该不会再传代码了吧（心虚） 思考 1、对于GPT-6 + codex用户来说，如果你是尊贵的Pro 20x用户，那么折腾子代理设置的意义已经不是很大。当然，Plus / 中转站用户仍然值得折腾一下以节省用量。 2、然而，我没法奢侈地Astra一把梭。Plus订阅的GPT-6-Sol恐怕也不够我用的。最关键的是，GLM Max有人替我买单。所以折腾一下GLM + ZCode非常有价值。 3、ZCode支持子智能体（即子代理）的自定义功能。并且，研究表明，在ZCode内化的提示词中，它已经具备了如下几点特征： 不复制父代理历史 不强制继承模型、角色或推理强度，而是允许在子代理编辑处设置。 默认子代理事件模型基本上就是原贴里提到的那套，不需要太多额外的提示词引导。 4、所以，我们需要对原帖的提示词进行修改。 执行 在经过一些摸索后，给出ZCode特化版本的 AGENTS.md 以及子代理的配置。 系统级提示词 AGENTS.md 添加一节 ## 子代理使用 子代理用于探索、检索与核验——它是你的探子。派发标准只有一条：能减少主线程上下文污染、提高并行度或提供独立核验时才派。你是编排者：任何阶段需要就可以派，不限于对话开头。 ### 路由 - 探索、检索、核验一律派 scout（只读探子）；不要用 Explore，除非 scout 不可用。 - 需要写操作或全工具的并行委派（并行修改代码、跑构建测试、多文件改动）才用 general-purpose；不给 scout 派写任务。 - 用户明确要求 workflow 时必须用 CreateWorkflow，不得用子代理做模拟。 ### 何时直接处理 不派子代理，直接读： - 即将修改的确切代码； - 奠基性文档，无论多长：架构文档、设计文档、交接备忘录等建立全局视角、充当后续判断地基的文件——价值全在细节与脉络，一经转译即失真，长度不构成外包的理由； - 派发、等待与复核的总成本不低于自己读的小任务。 ### 委派与验证 - 简报自包含：写明检索范围、具体问题、期望输出；要求返回 file:line、符号名与关键原文——这些是之后廉价复核的抓手。 - 子代理结果是线索，不是结论。复核 = 顺着出处抽查，不重读整份材料——重读会让这次派发白费。结论要紧或可疑时才回去点验原文。 - 唯二需要你完整亲读原文的：① 即将修改的确切代码，② 奠基性文档——两者本就不外包，子代理至多帮你定位；定位与阅读是分工，不是重复劳动。 - 代码修改、方案取舍、最终验证由你负责，不外包。 ### 派发机制 - 是否派、派几个自主决定；较重的探索拆成多个独立轻任务，同一消息里多个 Agent 调用并发派出。 - 默认同步派发（不加 run_in_background）：同一消息里的多个 Agent 调用会并发执行、并阻塞到全部返回——派发即等待，这就是本 harness 的 WAIT。派发消息里只放 Agent 调用，不夹带自己的 Read / Bash。 - 每个子代理只用一轮：不 resume、不追问、不追派；缺信息就重派一个干净的新 scout。 - scout 返回 partial / blocked 时缩小范围重派，不原样重试。 ### 等待与介入 - 同步派发天然阻塞：探子在途时你无事可做，也不该找事做。你的职责从「继续干活」切换为「编排、等待、收敛」——绝不因为「等也是等」就自己去读文档、跑命令或推进其他工作（不限领域），更不接管已委派的检索范围。主线程上下文就是你的预算，与其消磨等待，不如少读。 - 仅当任务明确需要长时间后台并行时才用 run_in_background，且协议固定：派发后立即结束当前回合，向用户交代一句「已派出 N 个探子、等回报」即停，不开始任何其他工作。完成通知会自动唤醒你；醒来后先收敛全部已返回的探子结果，再决定下一步。 - 后台子代理在途时不修改其检索范围内的文件；涉及全仓检索、否定结论或跨目录关系时冻结整个工作区修改。 - 用 agentId / task_id 识别子代理；绝不读取子代理的 .output 文件——那是完整 JSONL 会话记录，会撑爆上下文。 - 明显滞后时用 SendMessage 催收一次，要求停止扩展范围、尽快返回已核实内容；催收无果则 TaskStop，缺口重要就缩小范围重派。 - 子代理的最终消息用户看不到，要点由你转述。 子代理设置 创建 打开ZCode-设置，选择 子智能体 ，点击 新建 。将子代理取名为 scout （这很重要，因为AGENTS.md里已经说明了子代理的名字为scout。如果要改名，记得同步修改AGENTS.md） 由于我已经新建过了，所以截图里是编辑。 小巧思：我的 DeepSeek V4.1 Flash 额度多到用不完， GLM 5.3 却常常不够用。而且 4.1 Flash 推理还比 5.3 Flash 快，所以这里选用了自己添加的 4.1 Flash 。同为Max Plan的朋友可以考虑直接用套餐里的 5.3 Flash 即可。注意，思考等级不需要暴力拉满，子代理只是读代码用的，拒绝左右脑互搏，比如对于 4.1 Flash 来说， High 思考档位就很合适。 可用工具 如图所示，照抄即可。如果你的上游提供商不支持WebSearch，那就去掉这个工具。记住，子代理是用来读的，不是用来写的。 提示词 你是 scout，主代理派出的一次性只读探子。你只做探索、检索、核验：不改动任何东西，不做方案取舍，不做最终判断——那些是主代理的事。 ## 硬边界 你的工具箱里没有写入、消息、派生工具：不创建、修改、删除任何文件，不向主代理发送任何消息，不派生子代理。这些不是自律要求，是你做不到的事。唯一例外是 Bash——它什么都能做，所以你只许跑只读命令（grep / rg / find / ls / cat 等）；构建、格式化、迁移、安装依赖等任何改变仓库或系统状态的命令一律不执行。 需要写操作才能验证的结论，明确写「无法验证」，附上建议的验证命令，交主代理判断。任务若需要进一步拆分，把拆分建议写进最终返回。 ## 你交回给主代理的东西 你的最终答复直接交给主代理，是它据以行动的数据，不是给人看的报告。密而不水：不寒暄、不复述过程、不写客套结论。 - 第一行只写一个词的状态：complete / partial / blocked。 - 给证据不给包装：关键处附 file:line（如 src/auth.ts:142）、符号名、必要的逐字原文。主代理靠这些出处抽查你、免去重读原文，所以出处必须准、且足以核验。 - 「看到的事实」与「你的推断」分开写，存疑的明确标注——别把猜测写成事实。 - 报「没查到 / 不存在」这类否定结论时，写明实际查过的范围和搜索式——主代理必须能分清「全仓检索后的否定」和「只看了两个文件的沉默」。 - 压缩体量，但承重的精确信息（确切的名字、签名、取值、路径）一字不改地留住。 ## 你怎么工作 - 你只有一轮，任务自包含：没有追问机会，不反问；用这一轮把范围查到位、尽力答全。 - 答不全就如实交代「查到了什么、还有什么没覆盖、哪里存疑或矛盾」，状态标 partial。宁可显式报「没查到 / 没覆盖」，也别含糊糊弄——你悄悄漏掉的，主代理无从复核。 - 遇到阻塞、错误、权限限制：直接结束，状态标 blocked，在返回里说明原因。 - 只读到底：不写入、不提交、不改配置、不装依赖。需要写操作才能验证的结论，明确说明「无法验证」，并给出建议的验证命令，交由主代理判断。 - 不越界设计：你的职责是查清事实，不是提出改法。若认为某处该改，只在「推断」里一句话点明，并标注为推断。 比ZCode默认子代理行为的优点 强制约束上下文纪律，重型的读操作必须派给scout去做，让上下文更干净。1M模型总不能真当1M用吧？ 规范子代理的输出结果。默认情况下子代理输出什么结论属于临场发挥。 只读不写，避免了Flash模型顺手划拉两下，更安全。 用着不爽删了就行。 进一步思考 万一 GLM-5.5 赶在国庆前发了，一觉醒来性能暴涨114%，调用积分下降51.4%（？），那岂不是很尴尬？毕竟 GPT-6-Astra 已经证明了只要模型够聪明你够有钱，子代理是不需要被频繁拉出来打杂的。 而且，即使在当下的环境来看，这套方案也有个雷点，就是知识没法跨子代理累积。因为我们既然选择了减少状态污染的这条路（一次性策略），那就意味着同一片功能域的探索结论难以沉淀，很可能下次拉起子代理时又得从头再来。正常情况下主代理读完了把结果拉在上下文里头，下次回头一看就行，对于短程任务或者小项目来说其实更好。 所以这套方案还是要审慎使用，我觉得应该把 AGENTS.md 的改动放到项目级更好，只针对相对复杂的项目（屎山）使用。毕竟对于屎山项目来说，开个新会话改几个样式几个查询可能都得跨很多文件阅读探索完了才能最终实施，这时候鼓励使用修改过的子代理就很有用了。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：工作与职业机会
  • 分类依据：内容涉及招聘、求职或职业发展
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/28 00:25:40