尧图网页设计 
1. TRAE SOLO 模式系统提示词到底在约束什么TRAE SOLO 模式是 IDE 内自主执行任务的 Agent 形态它和普通代码补全最大的区别在于你给一个目标它自己拆任务、自己调工具、自己验证最后把结果端上来。而支撑这套行为的核心就是那份 18 段的系统提示词。很多人第一次看到它会觉得像在读一份“员工手册”——什么能做、什么不能做、做完怎么汇报全都写死了。我把它拆成三个观察角度工具调用约束、任务拆解粒度、上下文管理。这三个角度基本覆盖了 Agent 行为边界的定义方式。工具调用约束解决的是“它能碰什么、怎么碰”任务拆解粒度解决的是“它怎么把一句话需求变成可执行步骤”上下文管理解决的是“它记住什么、忘掉什么”。三者叠在一起才让 SOLO 模式在 IDE 里跑得像个靠谱的结对队友而不是一个等你喂指令的傀儡。这篇文章不打算逐条翻译那 18 段而是给你一套可复制的提示词结构模板再配上对照验证步骤。你可以拿它去拆自己手上的 Agent 提示词也可以直接改吧改吧用在自己的 LLM 应用里。适合谁看正在做 AI 编程工具、Agent 编排、或者单纯想搞明白“为什么有些 Agent 干活利索、有些只会问你要不要继续”的开发者。先说结论SOLO 模式的提示词设计逻辑本质是把“资深工程师的工作习惯”翻译成自然语言约束。它不教模型怎么写代码它教模型怎么像一个有判断力的工程师那样行动。下面逐层拆。2. TaoToken 前置给 Agent 一个稳定的模型入口在拆提示词之前得先解决一个现实问题SOLO 模式这类 Agent 对模型的推理稳定性要求很高因为它要连续多轮自主决策。如果你本地调试时模型入口不稳定提示词写得再好也白搭。我自己的做法是先把模型调用层固定下来再谈提示词调优。TaoToken 在这里的角色就是一个统一的模型接入层。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。它的价值在于你不需要为每个模型单独维护一套鉴权和路由逻辑Agent 侧只认一个 Base URL 和一个 Key。具体操作上你需要在控制台创建一个 API Key。入口在 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。创建完之后把 Base URL 和 Key 填进你的 Agent 配置里。如果你用的是 Claude Code 这类工具接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 里面有完整的配置说明。这里要强调一点SOLO 模式的提示词里有大量“强制验证”“并行调用”“记忆管理”的约束这些约束会显著增加单次任务的 token 消耗和调用轮次。所以模型入口的稳定性直接决定了你调试提示词时的体验。我试过在入口不稳定的情况下调提示词结果分不清是提示词写得烂还是请求超时白白浪费一下午。如果你只是想在本地验证提示词结构可以用模型对话功能快速试https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。把提示词粘进去给一个具体任务看它怎么拆、怎么调工具、怎么收尾。这一步不需要写代码适合先摸清行为边界。对于长期跑编码 Agent 的场景Coding Plan 会更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。它的定位是给持续性的编码任务提供稳定的调用额度避免你在调提示词的过程中被额度打断思路。把模型入口固定好之后下面进入正题提示词结构模板。3. 可复制的 SOLO 风格提示词结构模板这一节给你一份可以直接改的提示词骨架。它不是照抄 TRAE 原文而是把 18 段的核心约束提炼成 6 个模块每个模块对应一个行为边界。你可以把它存成solo_prompt.md或者直接塞进你的 Agent 配置文件。先看整体结构# Role You are a code assistant operating in an IDE, focused on software engineering tasks. You are pair-programming with the user. Each message includes their state (open file, cursor position, task context). Your goal is to follow the users instruction in every message. # Output Style Focus on engineering tasks. Provide educational explanations when needed. Balance task completion with clear, relevant technical insight. # Proactiveness and Persistence - Persist until the task is complete. - Check whether plan mode is enabled before acting. - Force verification: only finish after confirming the change works. - If uncertain, guide the user toward a direction and continue. - Make the most reasonable assumption and proceed. - Never ask the user whether to continue the plan. Execute, then ask whether they accept the implemented changes. # Task Management - Judge task complexity first. - If simple: execute directly. - If complex: create a todo list first. - Do not track per-file todos. - Do not end the task before all todos are done. # Tool Usage Policy - Never mention tool names to the user. Describe functionality in natural language. - Prefer specialized tools over terminal commands. - Parallelize independent tool calls (e.g., reading multiple files). - Never parallelize file edit tools. - Never parallelize RunCommand. # Validating Your Work - Ensure changes take effect and are correct. - Choose verification methods flexibly: unit tests, shell commands, etc. - Create and run tests when appropriate. - Never return unverified results. - For web projects, use preview to show the updated page. # Memory - Use manage_core_memory to record reusable, valuable history. - Allowed: project knowledge, tech stack rationale, stable troubleshooting paths, reusable user preferences, core architecture patterns. - Prohibited: current task goals, subtask progress, non-transferable reflections. - Merge related memories with UPDATE instead of ADD. - Append mccoremem / when referencing core memory.这份模板的关键在于每一条约束都对应一个可观察的行为。比如“Never parallelize file edit tools”对应的是你会在日志里看到编辑操作是串行的“Force verification”对应的是它不会在没跑测试的情况下说“已完成”。如果你用的是 JSON 配置比如某些 Agent 框架可以这样写{ agent: { role: ide_code_assistant, pair_programming: true, persistence: { until_complete: true, check_plan_mode: true, force_verification: true, never_ask_to_continue: true }, task_management: { complexity_check: true, todo_list_threshold: complex_only, no_per_file_todos: true }, tool_policy: { hide_tool_names: true, prefer_specialized_tools: true, parallel_read: true, parallel_edit: false, parallel_run_command: false }, memory: { tool: manage_core_memory, allowed_types: [knowledge, tech_stack, troubleshooting, preferences, architecture], prohibited_types: [plan, reflection], merge_strategy: UPDATE } } }注意parallel_edit和parallel_run_command都是false。这是 SOLO 模式里很关键的一条读操作可以并行写操作必须串行。原因很简单并行编辑同一个文件会冲突并行跑命令会互相干扰。这个约束在提示词里是用自然语言写的但落到配置里就是两个布尔值。再给一个 TOML 版本适合用配置文件管理 Agent 的场景[agent] role ide_code_assistant pair_programming true [agent.persistence] until_complete true check_plan_mode true force_verification true never_ask_to_continue true [agent.task_management] complexity_check true todo_list_threshold complex_only no_per_file_todos true [agent.tool_policy] hide_tool_names true prefer_specialized_tools true parallel_read true parallel_edit false parallel_run_command false [agent.memory] tool manage_core_memory allowed_types [knowledge, tech_stack, troubleshooting, preferences, architecture] prohibited_types [plan, reflection] merge_strategy UPDATE这三个版本的内容是一致的你可以根据自己用的框架选一个。重点不是格式而是把“行为边界”显式写出来。SOLO 模式的提示词之所以有效就是因为它把很多隐式的工作习惯变成了显式约束。模板给完了下面说怎么验证它真的生效。4. 验证请求与成功结果对照提示词写完不是终点你得能观察到它有没有按预期行动。这一节给你一套对照验证步骤用具体任务来触发不同约束。先准备一个测试任务比如“在当前项目里新增一个utils/date_helper.py提供一个format_iso(dt)函数并补一个单元测试。”第一步验证任务拆解粒度。把提示词和任务一起发给 Agent观察它是否先判断复杂度。如果它直接开始写文件说明complexity_check没生效如果它先输出一个 todo list说明生效了。成功的结果长这样我先看一下项目结构然后创建文件并补测试。 - [ ] 查看现有 utils 目录结构 - [ ] 创建 date_helper.py - [ ] 编写 format_iso 函数 - [ ] 添加单元测试 - [ ] 运行测试验证注意它没有问“你确定要创建吗”而是直接开始。这就是never_ask_to_continue的效果。第二步验证工具调用约束。看它的执行日志或者让它自己汇报步骤。成功的结果里读操作应该是并行的比如同时读取utils/下多个文件写操作应该是串行的创建文件和写测试不会同时发生。如果你看到它并行编辑两个文件说明parallel_edit约束没写进去。第三步验证强制验证。任务完成后它应该跑一次测试然后才说完成。成功的结果类似测试通过1 passed in 0.12s 已完成 date_helper.py 和对应测试。如果它没跑测试就说“已完成”说明force_verification没生效。第四步验证记忆管理。给它一个跨会话的任务比如先告诉它“这个项目统一用 black 格式化”然后开一个新会话问它格式化相关的问题。成功的结果是它能引用这条偏好并在回答里带上mccoremem /标签。如果它完全不记得说明记忆模块没接上。这里给一个具体的验证请求示例你可以直接复制curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [ {role: system, content: 把上面的 solo_prompt.md 内容粘这里}, {role: user, content: 在当前项目新增 utils/date_helper.py提供 format_iso(dt) 函数并补单元测试。} ] }跑完之后看返回内容里有没有 todo list、有没有验证步骤、有没有问“是否继续”。这三个观察点就能判断提示词结构有没有生效。如果你用的是 Claude Code 这类工具配置方式略有不同。需要在 settings 里填 Base URL、Key 和 Model ID 三件套。Base URL 用 https://taotoken.net/api Key 用你在控制台创建的那个Model ID 填你实际要用的模型标识。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 里有完整说明。验证通过之后你可能会遇到一些报错。下一节专门排障。5. 本篇常见错误排查这一节列几个我在调 SOLO 风格提示词时真实踩过的报错以及对应的排查方向。第一个401 Unauthorized。这个最常见通常是 Key 没填对或者没带上。检查你的请求头里有没有Authorization: Bearer key以及 Key 是不是从控制台复制完整了。如果你用的是 Claude Code检查 settings 里的 Key 字段有没有多余空格。还有一种情况是 Base URL 写错了比如写成了https://taotoken.net/api/带尾斜杠有些客户端会拼出双斜杠导致鉴权失败。正确写法是 https://taotoken.net/api 不带尾斜杠。第二个local proxy failed。这个报错通常出现在你本地配了转发规则但目标地址不通的时候。排查顺序是先确认 Base URL 能不能直接访问再确认本地配置有没有覆盖全局设置。如果你在 settings 里同时配了多个入口客户端可能选了错误的那个。建议只保留一个入口把其他的注释掉。第三个reading choices相关报错。这个一般出现在流式响应解析阶段原因是返回结构和你客户端预期的格式不一致。排查方法是先用非流式请求测一次看返回的 JSON 结构里有没有choices字段。如果没有说明模型 ID 填错了或者入口不支持该模型。把 Model ID 换成确认可用的再试。第四个OAuth相关报错。如果你用的是需要 OAuth 的工具检查 token 有没有过期。有些工具的 OAuth 流程和 API Key 是两套体系别混用。如果你只是调 API直接用 Key 就行不需要走 OAuth。第五个Agent 不执行、只回复“我建议你……”。这个不是报错但比报错更烦。原因是提示词里的proactiveness约束没写到位。检查有没有这几条never_ask_to_continue、make_reasonable_assumption、persist_until_complete。缺任何一条模型都可能退化成“建议模式”。第六个Agent 并行编辑文件导致冲突。检查parallel_edit有没有显式设为 false。有些框架默认允许并行工具调用你不写死它就会并行。SOLO 模式里这条是硬约束必须写。第七个记忆不生效或者记忆爆炸。如果记忆完全不生效检查manage_core_memory工具有没有注册。如果记忆条目越来越多检查merge_strategy有没有设为 UPDATE以及prohibited_types有没有把 plan 和 reflection 排除掉。SOLO 模式的记忆设计核心是“提炼知识不是记流水账”。排障的时候有个通用技巧把 Agent 的中间步骤日志打开。SOLO 模式的价值在于过程可观察如果你只看最终结果很难判断是提示词问题还是模型问题。日志里能看到它调了哪些工具、按什么顺序调、有没有验证这些信息比最终答案更有诊断价值。如果你在排障过程中需要快速验证某个模型的行为可以用模型对话功能单独测https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。把提示词和任务粘进去看它怎么反应比在完整 Agent 环境里调快得多。6. 把提示词约束变成可复用的 Agent 能力拆完这 18 段我最大的感受是SOLO 模式的提示词设计重点不在“教模型做事”而在“给模型授权并划边界”。它把“假设权”“数据控制权”“验证责任”都交给了模型同时用明确的禁止项兜底。这种设计思路比堆一堆“你要认真负责”之类的空话有效得多。如果你想把这套思路用到自己的项目里建议从三个动作开始。第一把你的 Agent 提示词按“角色、主动性、任务管理、工具策略、验证、记忆”六个模块重写一遍每个模块只写可观察的行为约束。第二给每条约束配一个验证步骤写完就测别等上线才发现没生效。第三把记忆管理单独拎出来设计明确什么该记、什么不该记、怎么合并这是长期跑 Agent 最容易翻车的地方。工具调用约束这块核心就一句话读可以并行写必须串行。任务拆解粒度这块核心是“先判断复杂度再决定要不要 todo list”。上下文管理这块核心是“记知识不记流水账”。这三条抓住了你的 Agent 行为边界就立住了。最后留一个实操建议拿你今天正在做的任务用第 3 节的模板写一版提示词然后用第 4 节的验证步骤跑一遍。跑完你会对“哪些约束真正影响行为”有更具体的感知。提示词调优没有捷径就是写、测、改。 TRAE SOLO 模式系统提示词拆解：Agent 行为边界与工具调用约束
1. TRAE SOLO 模式系统提示词到底在约束什么TRAE SOLO 模式是 IDE 内自主执行任务的 Agent 形态它和普通代码补全最大的区别在于你给一个目标它自己拆任务、自己调工具、自己验证最后把结果端上来。而支撑这套行为的核心就是那份 18 段的系统提示词。很多人第一次看到它会觉得像在读一份“员工手册”——什么能做、什么不能做、做完怎么汇报全都写死了。我把它拆成三个观察角度工具调用约束、任务拆解粒度、上下文管理。这三个角度基本覆盖了 Agent 行为边界的定义方式。工具调用约束解决的是“它能碰什么、怎么碰”任务拆解粒度解决的是“它怎么把一句话需求变成可执行步骤”上下文管理解决的是“它记住什么、忘掉什么”。三者叠在一起才让 SOLO 模式在 IDE 里跑得像个靠谱的结对队友而不是一个等你喂指令的傀儡。这篇文章不打算逐条翻译那 18 段而是给你一套可复制的提示词结构模板再配上对照验证步骤。你可以拿它去拆自己手上的 Agent 提示词也可以直接改吧改吧用在自己的 LLM 应用里。适合谁看正在做 AI 编程工具、Agent 编排、或者单纯想搞明白“为什么有些 Agent 干活利索、有些只会问你要不要继续”的开发者。先说结论SOLO 模式的提示词设计逻辑本质是把“资深工程师的工作习惯”翻译成自然语言约束。它不教模型怎么写代码它教模型怎么像一个有判断力的工程师那样行动。下面逐层拆。2. TaoToken 前置给 Agent 一个稳定的模型入口在拆提示词之前得先解决一个现实问题SOLO 模式这类 Agent 对模型的推理稳定性要求很高因为它要连续多轮自主决策。如果你本地调试时模型入口不稳定提示词写得再好也白搭。我自己的做法是先把模型调用层固定下来再谈提示词调优。TaoToken 在这里的角色就是一个统一的模型接入层。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。它的价值在于你不需要为每个模型单独维护一套鉴权和路由逻辑Agent 侧只认一个 Base URL 和一个 Key。具体操作上你需要在控制台创建一个 API Key。入口在 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。创建完之后把 Base URL 和 Key 填进你的 Agent 配置里。如果你用的是 Claude Code 这类工具接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 里面有完整的配置说明。这里要强调一点SOLO 模式的提示词里有大量“强制验证”“并行调用”“记忆管理”的约束这些约束会显著增加单次任务的 token 消耗和调用轮次。所以模型入口的稳定性直接决定了你调试提示词时的体验。我试过在入口不稳定的情况下调提示词结果分不清是提示词写得烂还是请求超时白白浪费一下午。如果你只是想在本地验证提示词结构可以用模型对话功能快速试https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。把提示词粘进去给一个具体任务看它怎么拆、怎么调工具、怎么收尾。这一步不需要写代码适合先摸清行为边界。对于长期跑编码 Agent 的场景Coding Plan 会更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。它的定位是给持续性的编码任务提供稳定的调用额度避免你在调提示词的过程中被额度打断思路。把模型入口固定好之后下面进入正题提示词结构模板。3. 可复制的 SOLO 风格提示词结构模板这一节给你一份可以直接改的提示词骨架。它不是照抄 TRAE 原文而是把 18 段的核心约束提炼成 6 个模块每个模块对应一个行为边界。你可以把它存成solo_prompt.md或者直接塞进你的 Agent 配置文件。先看整体结构# Role You are a code assistant operating in an IDE, focused on software engineering tasks. You are pair-programming with the user. Each message includes their state (open file, cursor position, task context). Your goal is to follow the users instruction in every message. # Output Style Focus on engineering tasks. Provide educational explanations when needed. Balance task completion with clear, relevant technical insight. # Proactiveness and Persistence - Persist until the task is complete. - Check whether plan mode is enabled before acting. - Force verification: only finish after confirming the change works. - If uncertain, guide the user toward a direction and continue. - Make the most reasonable assumption and proceed. - Never ask the user whether to continue the plan. Execute, then ask whether they accept the implemented changes. # Task Management - Judge task complexity first. - If simple: execute directly. - If complex: create a todo list first. - Do not track per-file todos. - Do not end the task before all todos are done. # Tool Usage Policy - Never mention tool names to the user. Describe functionality in natural language. - Prefer specialized tools over terminal commands. - Parallelize independent tool calls (e.g., reading multiple files). - Never parallelize file edit tools. - Never parallelize RunCommand. # Validating Your Work - Ensure changes take effect and are correct. - Choose verification methods flexibly: unit tests, shell commands, etc. - Create and run tests when appropriate. - Never return unverified results. - For web projects, use preview to show the updated page. # Memory - Use manage_core_memory to record reusable, valuable history. - Allowed: project knowledge, tech stack rationale, stable troubleshooting paths, reusable user preferences, core architecture patterns. - Prohibited: current task goals, subtask progress, non-transferable reflections. - Merge related memories with UPDATE instead of ADD. - Append mccoremem / when referencing core memory.这份模板的关键在于每一条约束都对应一个可观察的行为。比如“Never parallelize file edit tools”对应的是你会在日志里看到编辑操作是串行的“Force verification”对应的是它不会在没跑测试的情况下说“已完成”。如果你用的是 JSON 配置比如某些 Agent 框架可以这样写{ agent: { role: ide_code_assistant, pair_programming: true, persistence: { until_complete: true, check_plan_mode: true, force_verification: true, never_ask_to_continue: true }, task_management: { complexity_check: true, todo_list_threshold: complex_only, no_per_file_todos: true }, tool_policy: { hide_tool_names: true, prefer_specialized_tools: true, parallel_read: true, parallel_edit: false, parallel_run_command: false }, memory: { tool: manage_core_memory, allowed_types: [knowledge, tech_stack, troubleshooting, preferences, architecture], prohibited_types: [plan, reflection], merge_strategy: UPDATE } } }注意parallel_edit和parallel_run_command都是false。这是 SOLO 模式里很关键的一条读操作可以并行写操作必须串行。原因很简单并行编辑同一个文件会冲突并行跑命令会互相干扰。这个约束在提示词里是用自然语言写的但落到配置里就是两个布尔值。再给一个 TOML 版本适合用配置文件管理 Agent 的场景[agent] role ide_code_assistant pair_programming true [agent.persistence] until_complete true check_plan_mode true force_verification true never_ask_to_continue true [agent.task_management] complexity_check true todo_list_threshold complex_only no_per_file_todos true [agent.tool_policy] hide_tool_names true prefer_specialized_tools true parallel_read true parallel_edit false parallel_run_command false [agent.memory] tool manage_core_memory allowed_types [knowledge, tech_stack, troubleshooting, preferences, architecture] prohibited_types [plan, reflection] merge_strategy UPDATE这三个版本的内容是一致的你可以根据自己用的框架选一个。重点不是格式而是把“行为边界”显式写出来。SOLO 模式的提示词之所以有效就是因为它把很多隐式的工作习惯变成了显式约束。模板给完了下面说怎么验证它真的生效。4. 验证请求与成功结果对照提示词写完不是终点你得能观察到它有没有按预期行动。这一节给你一套对照验证步骤用具体任务来触发不同约束。先准备一个测试任务比如“在当前项目里新增一个utils/date_helper.py提供一个format_iso(dt)函数并补一个单元测试。”第一步验证任务拆解粒度。把提示词和任务一起发给 Agent观察它是否先判断复杂度。如果它直接开始写文件说明complexity_check没生效如果它先输出一个 todo list说明生效了。成功的结果长这样我先看一下项目结构然后创建文件并补测试。 - [ ] 查看现有 utils 目录结构 - [ ] 创建 date_helper.py - [ ] 编写 format_iso 函数 - [ ] 添加单元测试 - [ ] 运行测试验证注意它没有问“你确定要创建吗”而是直接开始。这就是never_ask_to_continue的效果。第二步验证工具调用约束。看它的执行日志或者让它自己汇报步骤。成功的结果里读操作应该是并行的比如同时读取utils/下多个文件写操作应该是串行的创建文件和写测试不会同时发生。如果你看到它并行编辑两个文件说明parallel_edit约束没写进去。第三步验证强制验证。任务完成后它应该跑一次测试然后才说完成。成功的结果类似测试通过1 passed in 0.12s 已完成 date_helper.py 和对应测试。如果它没跑测试就说“已完成”说明force_verification没生效。第四步验证记忆管理。给它一个跨会话的任务比如先告诉它“这个项目统一用 black 格式化”然后开一个新会话问它格式化相关的问题。成功的结果是它能引用这条偏好并在回答里带上mccoremem /标签。如果它完全不记得说明记忆模块没接上。这里给一个具体的验证请求示例你可以直接复制curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [ {role: system, content: 把上面的 solo_prompt.md 内容粘这里}, {role: user, content: 在当前项目新增 utils/date_helper.py提供 format_iso(dt) 函数并补单元测试。} ] }跑完之后看返回内容里有没有 todo list、有没有验证步骤、有没有问“是否继续”。这三个观察点就能判断提示词结构有没有生效。如果你用的是 Claude Code 这类工具配置方式略有不同。需要在 settings 里填 Base URL、Key 和 Model ID 三件套。Base URL 用 https://taotoken.net/api Key 用你在控制台创建的那个Model ID 填你实际要用的模型标识。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 里有完整说明。验证通过之后你可能会遇到一些报错。下一节专门排障。5. 本篇常见错误排查这一节列几个我在调 SOLO 风格提示词时真实踩过的报错以及对应的排查方向。第一个401 Unauthorized。这个最常见通常是 Key 没填对或者没带上。检查你的请求头里有没有Authorization: Bearer key以及 Key 是不是从控制台复制完整了。如果你用的是 Claude Code检查 settings 里的 Key 字段有没有多余空格。还有一种情况是 Base URL 写错了比如写成了https://taotoken.net/api/带尾斜杠有些客户端会拼出双斜杠导致鉴权失败。正确写法是 https://taotoken.net/api 不带尾斜杠。第二个local proxy failed。这个报错通常出现在你本地配了转发规则但目标地址不通的时候。排查顺序是先确认 Base URL 能不能直接访问再确认本地配置有没有覆盖全局设置。如果你在 settings 里同时配了多个入口客户端可能选了错误的那个。建议只保留一个入口把其他的注释掉。第三个reading choices相关报错。这个一般出现在流式响应解析阶段原因是返回结构和你客户端预期的格式不一致。排查方法是先用非流式请求测一次看返回的 JSON 结构里有没有choices字段。如果没有说明模型 ID 填错了或者入口不支持该模型。把 Model ID 换成确认可用的再试。第四个OAuth相关报错。如果你用的是需要 OAuth 的工具检查 token 有没有过期。有些工具的 OAuth 流程和 API Key 是两套体系别混用。如果你只是调 API直接用 Key 就行不需要走 OAuth。第五个Agent 不执行、只回复“我建议你……”。这个不是报错但比报错更烦。原因是提示词里的proactiveness约束没写到位。检查有没有这几条never_ask_to_continue、make_reasonable_assumption、persist_until_complete。缺任何一条模型都可能退化成“建议模式”。第六个Agent 并行编辑文件导致冲突。检查parallel_edit有没有显式设为 false。有些框架默认允许并行工具调用你不写死它就会并行。SOLO 模式里这条是硬约束必须写。第七个记忆不生效或者记忆爆炸。如果记忆完全不生效检查manage_core_memory工具有没有注册。如果记忆条目越来越多检查merge_strategy有没有设为 UPDATE以及prohibited_types有没有把 plan 和 reflection 排除掉。SOLO 模式的记忆设计核心是“提炼知识不是记流水账”。排障的时候有个通用技巧把 Agent 的中间步骤日志打开。SOLO 模式的价值在于过程可观察如果你只看最终结果很难判断是提示词问题还是模型问题。日志里能看到它调了哪些工具、按什么顺序调、有没有验证这些信息比最终答案更有诊断价值。如果你在排障过程中需要快速验证某个模型的行为可以用模型对话功能单独测https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。把提示词和任务粘进去看它怎么反应比在完整 Agent 环境里调快得多。6. 把提示词约束变成可复用的 Agent 能力拆完这 18 段我最大的感受是SOLO 模式的提示词设计重点不在“教模型做事”而在“给模型授权并划边界”。它把“假设权”“数据控制权”“验证责任”都交给了模型同时用明确的禁止项兜底。这种设计思路比堆一堆“你要认真负责”之类的空话有效得多。如果你想把这套思路用到自己的项目里建议从三个动作开始。第一把你的 Agent 提示词按“角色、主动性、任务管理、工具策略、验证、记忆”六个模块重写一遍每个模块只写可观察的行为约束。第二给每条约束配一个验证步骤写完就测别等上线才发现没生效。第三把记忆管理单独拎出来设计明确什么该记、什么不该记、怎么合并这是长期跑 Agent 最容易翻车的地方。工具调用约束这块核心就一句话读可以并行写必须串行。任务拆解粒度这块核心是“先判断复杂度再决定要不要 todo list”。上下文管理这块核心是“记知识不记流水账”。这三条抓住了你的 Agent 行为边界就立住了。最后留一个实操建议拿你今天正在做的任务用第 3 节的模板写一版提示词然后用第 4 节的验证步骤跑一遍。跑完你会对“哪些约束真正影响行为”有更具体的感知。提示词调优没有捷径就是写、测、改。