写在前面的观点是，最先想到的方案。往往也是最先失控的方案

团队在做 AI 桌面端工具的 Chat 与 Agent Work 时最先遇到的问题通常很直接：模型回答不够稳定，那就补 Prompt。

角色不够清楚？话说回来，加一段身份说明。工具不会用，再加几条规则。使用者想要特定格式，继续往 system prompt 里塞。

刚开始效果往往不错，但需求一多。Prompt 就会慢慢长成“谁也不敢动的大字符串”：产品规则、使用者偏好、工具说明、运行时状态和历史事实全挤在一起。

所以，本篇借 Cherry Studio 的实现。拆解怎样把 Prompt 从一段文案，变成可组合、可评审的行为契约。

. Prompt Engineering 的目标不是“写得更长”

在普通问答中，Prompt 常被理解为一段调整回答质量的自然语言指令。老实说，进入 Agent 场景后它承担的角色更接近行为契约

• Agent 是谁。服务于谁，
• 在什么条件下应该使用什么工具。
• 何时应询问使用者、引用来源、保存记忆或停止执行。
• 哪些能力不存在不能假装已经完成。

. Prompt 的演化：从单层字符串到分层策略

单层 Prompt 的局限

system = "你是一个专业助手，请回答使用者问题。" response = model.generate

• 产品级规则、使用者偏好和任务要求混在一起,无法分别演进。
• 长期事实只能不断往 Prompt 追加,最终造成噪声和 token 成本膨胀。
• 工具随运行时配置变化,但仍声称具备已被禁用的能力。
• 使用者自定义指令和产品内置指令可能互相覆盖.

推荐的分层模型

• A. Identity – “你是谁？” – 配置或Agent网站团队
• A. ProductPolicy – “产品要求你遵守什么?” – 网站团队
• A. ToolStrategy – “何时/如何使用工具?” – 工具/Agent团队
• A. RuntimeContext – “你现在处于哪个环境?” – 运行时
• A. UserInstructions – “这个使用者要求你怎样工作?” – 使用者
• ” -Agent + 使用者
• A. TaskSpecificGuidance -“这一轮任务有什么额外要求?” -请求构造层 "分层不是为了让Prompt更复杂,而是为了让每层都有明确更新规则."

.回到Cherry Studio:两条Prompt组装方法.

"Cherry Studio不是所有对话都使用同一套Prompt."

"普通Chat与长期运行Agent Session,面对的是不同任务边界." .

"硬塞进同一份模板只会让两边都别扭."

普通Chat → buildAgentParams → assembleSystemPrompt → AI SDK Agent

AgentSession → ClaudeCode settingsBuilder → PromptBuilder.buildSystemPrompt → ClaudeCode Runtime Driver

从主要思路来看。最终暴露什么能力,Prompt才描述什么能力. 主要思路: 每段都由运行时事实决定:

-工作区方法来自当前session不能写死.

-如果包含tool_search追加延迟发现指引. -如果有可引用查询追加格式指引. -引用指引只在Web/知识库存在时添加. 频道安全规则只在连接外部频道添加. 环境由实际提供.

伪代码 assembleSystemPrompt{ sections=;if{ sections.push);} if){ sections.push);} return sections.join;} 伪代码 buildAgentSession{ base=await promptBuilder.build;return joinNonEmpty();}

说到.关键算法一，先把优先级说清楚.

.

• 默认值应来自版本管理内置内容.
• 显示编辑后应该覆盖默认值.
• 清空后恢复随产品升级而更新. 是否内置角色?

  是否非空自定义?

  返回结果

isBuiltinRoleExists.

'TRUE/NOT EMPTY'. 'LOAD BUILTIN DEFINITION'.

'FALSE/EMPTY'. 'RETURN USER INSTRUCTIONS'.

...

---