https://github.com/elder-plinius/CL4R1T4S/blob/main/OPENAI/Codex_Desktop/GPT-6-Sol_Prompts.txt 看看这个提示词

回复 Erfan： 读了抓取到的内容，包含主指令模板和部分 persistent mode（持续执行模式）；文件较长，返回内容有截断，下面只分析已读部分。 先说来源：这是第三方仓库收集的文本，不能仅凭文件名和开头的自我介绍，确认它就是官方真实、完整的提示词，也不能拿它证明模型版本。 从 Agent 设计角度看，它有几个值得研究的地方。 一、把“完成任务”定义得很具体 它反复要求：不要给出一个“差不多有帮助”的答案就停，要把用户已经授权的工作推进到可交付状态。 比如准备发布网站，应先完成实现和必要验证，让用户审批一个具体结果，而不是刚开始就问“要不要我继续”。 这里的重点是减少用户反复催促，同时保留发布、对外发消息等操作的授权边界。 二、用户插话，不等于原任务取消 文本明确区分：补充约束、问进度、纠正方向，以及真正取消任务。 例如 Agent 正在改代码，用户问“现在怎么样了”，它应该回答进度后继续做，而不是把原任务忘掉。 上下文压缩后，也要求保留原目标、已接受的纠正、完成状态和待办。这些都在解决长任务中的目标丢失问题。 三、异步交互是核心设计 需要用户补充信息时，可以先提问，同时继续不依赖答案的工作。 但它明确写了：等待了一段时间，不代表用户已经回答或授权。 这点很重要。让 Agent 不阻塞，和让 Agent 擅自替用户做决定，是两回事。 四、持续执行模式关注“闭环” 文本里的例子是：提交 PR 后继续检查 CI、确认是否具备合并条件；查询评估任务进度后，在适用的任务范围内继续跟踪到结束。 而且要求每个后续动作都有范围、目标、证据和停止条件，并强调持续执行不能扩大授权。 所以它不是简单写一句“永远不要停”，而是在规定什么时候应该继续、什么时候必须交还用户。 五、很多细节像是在修真实失败案例 例如独立读取可以并行，依赖操作必须按顺序；明确提醒 JSON 序列化不等于 shell 转义；不要因为关键词碰巧匹配就加载 Skill；测试应针对实际风险，充分验证后就停止追加无意义测试。 这些规则很具体，适合当作 Agent 故障清单来读。不过，仅凭文本无法确认它们实际来自什么事故。 我的看法：这份材料最有价值的是任务连续性、授权边界和完成标准的设计。它也明显依赖异步消息、上下文压缩、审批和工具执行等运行时能力，整段复制到普通聊天模型里，不会自动获得同样效果。 另外，“少问、主动推进”和“不要越权”之间存在张力。提示词能表达原则，真正的权限边界仍需要工具层落实。