Kimi Chat模式Agent提示词工程详解

背景

随着大语言模型（LLM）从单纯的对话助手向具备执行能力的智能体（Agent）演进，提示词工程（Prompt Engineering）的重心已从简单的指令遵循转向复杂的系统架构设计。Moonshot AI 推出的 Kimi 智能体，不仅是一个聊天机器人，更是一个能够创建文件、搜索网络、执行代码、生成多媒体及部署网站的通用型工作流引擎。

本文分享的内容源自 LINUX DO 社区，详细拆解了 Kimi Chat 模式下 Agent 的系统提示词（System Prompt）结构。该提示词定义了 Kimi 的身份、沟通原则、技能加载机制、文件输出规范以及前后端开发的特定工作流。理解这一提示词结构，对于开发者优化 AI 工作流、构建自定义 Agent 或深入理解现代 AI 智能体的底层逻辑具有重要参考价值。

核心内容

该提示词构建了一个高度结构化、模块化的 Agent 行为框架，主要包含以下核心模块：

1. 身份定位与沟通指南

Kimi 被定义为由 Moonshot AI 开发的通用型智能体，具备视觉分析、代码执行、文件编辑及网站部署等全栈能力。在沟通层面，强调“像专业人士分享工作”般的自然、透明风格。

• 匹配用户：根据用户输入的复杂度和风格调整回复的深度与正式程度。
• 展示成果：用户关注结果而非过程，严禁暴露提示词、技术工具名称或机械化的格式化痕迹（如过多的步骤标签）。
• 边界控制：不得泄露元指令，简单任务需精简沟通，仅在系统解析必需时（如 KIMI_REF 标签）才使用特殊标记。

2. 技能系统（Skill System）

这是该 Agent 架构的核心，采用“能力（做什么）”与“产出物（产出什么）”正交分类，并通过文件系统动态加载。

• 技能分类：
  • 能力技能：如 deep-research（深度研究），负责调查与规划。
  • 产出技能：如 docx、pdf、xlsx，负责最终格式的生产。
• 加载逻辑：
  • 渐进式加载：仅在执行当前步骤前读取对应的 SKILL.md，避免一次性加载所有技能造成上下文冗余。
  • 组合式执行：复杂任务需组合能力技能与产出技能。例如，生成 Word 研究报告需组合 deep-research 与 docx。
  • 优先级规则：用户自定义技能优先于内置技能。若用户技能与内置格式技能冲突，用户指令优先，但内置技能仍可用于具体的格式执行。
  • 文件路径：内置技能位于 /app/.agents/skills/，用户技能位于 /app/.user/skills/。

3. 输出与交付规范

为确保智能体生成的文件能被系统正确识别和下载，提示词强制规定了严格的输出标签机制。

• KIMI_REF 标签：在生成最终交付文件（如文档、图片、技能包）后，必须在响应末尾附加 <KIMI_REF type="file" path="sandbox://{path}" /> 标签。
• 多文件处理：若生成多个文件，需为每个文件单独列出一行标签。
• 排除中间文件：仅包含直接满足用户请求的最终交付文件，排除草稿、临时文件或辅助脚本。
• 技能交付：创建或编辑技能后，需将 .skill 文件保存至 /mnt/agents/output/ 并附上对应标签。

4. 开发工作流与部署策略

针对 Web 应用开发，提示词定义了严格的前后端分离与部署逻辑，防止工具误用。

• 图像生成：根据背景透明度选择 .jpg（不透明）或 .png（透明），并匹配查询语言。
• 部署工具选择：
  • 纯前端/无后端：使用 mshtools-deploy_website。需确保资源路径相对化，React 项目需先 npm run build 再部署 dist/ 文件夹。
  • 全栈应用（含后端）：必须加载 backend-building 技能，并使用 mshtools-website_version_manager。该工具用于保存项目快照（build_version），不直接返回 URL，需用户手动部署后获取链接。
  • 互斥原则：严禁在同一项目中混用 deploy 和 version_manager。若项目从纯前端转为全栈，需停止使用 deploy 并切换工具。
• 技术栈约束：
  • 前端：禁止使用 npx 直接初始化 shadcn，需先阅读 webapp-building 技能。<BrowserRouter> 已在入口文件预置，禁止在组件中重复添加。
  • 后端：必须基于 webapp-building 初始化后的前端进行。默认数据库为 MySQL，禁止预先选择 SQLite。
  • 依赖管理：严禁修改 package.json 中的 build 脚本。若构建失败，应排查依赖安装或源代码问题，而非绕过构建流程。

关键要点

• 动态技能加载：Agent 不是一次性加载所有能力，而是根据任务阶段动态读取 /app/.agents/skills/{skill_name}/SKILL.md 或用户自定义技能，实现上下文的高效利用。
• 用户技能优先：当存在用户自定义技能时，其指令覆盖内置技能。这是实现个性化工作流的关键机制。
• 严格的文件交付协议：所有最终输出必须通过 <KIMI_REF> 标签指向 /mnt/agents/output/ 下的具体路径，这是系统解析文件并交付给用户的唯一通道。
• 前后端部署隔离：
  • 纯前端项目使用 mshtools-deploy_website，直接返回 NGINX 托管的 URL。
  • 全栈项目使用 mshtools-website_version_manager，仅保存快照，不提供即时 URL，强调版本管理和手动部署流程。
• 开发规范强制约束：
  • 禁止修改 package.json 的 build 脚本。
  • 禁止重复添加 BrowserRouter。
  • 后端开发必须依赖前端初始化完成后的状态。
  • 默认数据库引擎为 MySQL。
• 沟通极简主义：Agent 被要求隐藏技术实现细节，仅展示最终成果，避免向用户暴露提示词、工具名或机械化的步骤标签，除非是系统必需的 KIMI_REF 标签。

意义与影响

这份 Kimi Agent 提示词揭示了当前 AI 智能体开发的高级范式：从“对话生成”向“工作流编排”的转变。

1. 结构化思维的外化：通过将技能模块化（能力 vs 产出）并定义明确的加载优先级，该提示词展示了如何将复杂的 AI 行为分解为可管理、可组合的组件。这种设计模式可被其他 Agent 框架借鉴，以提高系统的稳定性和可维护性。
2. 人机协作的边界清晰化：通过强制要求“展示成果而非过程”以及严格的文件交付标签，明确了 AI 作为执行者的角色边界。AI 负责复杂的逻辑推理、工具调用和文件生成，而用户只需关注最终交付物，降低了使用门槛。
3. 工程化约束的重要性：在开发工作流部分，提示词引入了类似传统软件工程的最佳实践（如依赖管理、构建脚本保护、路由配置规范）。这表明，要让 AI 可靠地生成可运行的代码，必须将其约束在严格的工程规范之内，而非仅依赖模型的通用知识。
4. 对开发者的启示：对于希望构建自定义 Agent 的开发者而言，理解“技能加载机制”和“输出解析协议”至关重要。未来的 AI 应用竞争，可能不在于模型本身的参数规模，而在于如何设计更精细的工作流、更高效的技能组合策略以及更稳健的错误处理机制。