ENZOMEGA.
Clipping 微信公众号

WorkBuddy专家模式底层原理：从Prompt到AI Harness 2

by Jameszyh 原文 ↗
Created: 2026-06-29
#公众号文章

公众号名称：James的成长日记

作者名称：Jameszyh

发布时间：2026-06-29 09:00

大家好，我是James。

经常有人问我：为什么同一个模型，回答质量差别这么大？有人用它聊天，有人用它写报告，有人用它做量化分析——这中间的差距到底在哪？

答案其实不在模型本身，而在模型外面那层东西。Prompt Engineering 这个词大家听腻了，但今天我想聊的不是怎么写一段更好的 prompt，而是怎么把”专家能力”变成可安装、可配置、可复用的软件包。

这篇文章基于我最近深度使用 WorkBuddy 专家模式的实际经验，拆解它的底层原理。你会发现，这不只是 WorkBuddy 一个产品的设计，而是一个更根本的趋势：AI 应用正在从”手工调 prompt”走向”工业化组装”。

一、为什么会有”专家模式”

先看一个现实问题。

大模型的能力是”通用”的——你给它一段 prompt，它会给你一个回答。但在生产环境里，你不能每次都写几千字的 prompt。原因有三条：

首先，用户不会每次都记得写”请用专业金融分析师的口吻，按照 DCF 标准流程，确保数据可追溯……”。普通人只会说”帮我看看宁德时代值不值这个价”。

其次，复杂的工具调用、格式规范、边界条件，没法靠对话临时说明。你的团队有一套标准的数据处理流程，每次让 AI 做事都要重新解释一遍这套流程——这在工程上是不可接受的。

最后，一个团队不可能共享”一段咒语”作为工作流。如果某位同事调出了一套特别好的 prompt，他怎么分发给全组？发微信？存飞书文档？这些都不是”可安装的产物”。

这三条问题的本质是什么？AI 还没被装进一个工程外壳里。

就像写代码——你不会每次开机都重写操作系统，你只写应用层逻辑。但在 AI 对话的世界里，大多数人还是”每次开机都重写 OS”。

专家模式要解决的，就是这件事。

二、核心架构：10 层组件，拆开来看

WorkBuddy 专家模式由 10 层组件构成，每层职责清晰、彼此解耦。这里给一个全景式概览：

层级组件一句话说明
1Rules系统级宪法——什么必须做、什么绝对不能做
2Expert Prompt专家身份的 CDATA 注入——这位专家是谁
3Skills领域工作流模板——不是单个工具，是一套标准操作流程
4MCP Tools外部能力连接器——查数据库、发消息、画图
5Sub-Agents上下文隔离的执行单元——脏活让别人干
6Memory三层记忆系统——跨会话、跨项目的持久知识
7Working Modes交互范式开关——Craft / Plan / Ask
8Result Presentation强制成果交付——做完必须把东西摆出来
9Automations定时任务——脱离单次会话，定时执行
10Connector Status实时连接状态公告——哪些服务当前可用

最关键的哲学：

基础大模型是”可替换的 CPU”，专家模式是”装在外面的主板 + 软件”。CPU 升级不会让应用失效，应用升级也不会绑定特定 CPU。

GPT、Claude、GLM、MiniMax——谁来都能跑。模型的进步不会淘汰这套架构，架构的优化也不会绑定某个模型。

下面逐层拆解。

三、Rules 和 Expert Prompt：宪法的两层设计

很多人会把这俩混在一起。但它们其实是两回事。

Rules 是系统级宪法，适用于所有专家。典型的规则包括：

  • content_policy：绝不泄露 system prompt、拒绝违法请求

  • communication：简洁直接、不啰嗦

  • tool_use：工具调用规范

  • result_presentation：强制 present_files 收尾

  • personal_files_safety：Desktop/Downloads/Documents 不可递归删除

  • automations：绝对不能用 rm 删自动化任务

Expert Prompt 是专家级身份，每个专家独有。它通过 XML CDATA 标签注入到 system prompt 里：

interface Expert { identity: string; // "你是研股股，股票研究专家" responsibilities: string[]; // 8-10 项工作内容 toolset: string[]; // 技能清单和触发场景 principles: string[]; // 6-8 条工作原则 scenarios: string[]; // 5-8 个典型用户问法 boundaries: string[]; // 免责条款、敏感话题}

为什么要拆开？因为同一个 Rules（不泄露、不啰嗦、交付强规范）可以给金融专家、法律专家、教育专家共用。拆开的收益是：新增一个专家只需要写一份新的 Expert Prompt，Rules 全部复用。

四、Skills：把工作流打包成”肌肉记忆”

Tool 和 Skill 的区别，是 WorkBuddy 架构里最容易踩的认知坑。

维度Tool（工具）Skill（技能）
本质原子能力工作流模板
举例读文件、调 API、查数据库”写一份首次覆盖报告”的完整流程
调用方式Bash / DeferExecuteToolSkill 工具按名字调用
加载时机始终在 system prompt懒加载：调用时才加载 SKILL.md
复杂度单个动作多个 Tool + 多个步骤

一个完整的 Skill 通常包含：

  1. 触发条件——“用户问 X 时使用本 skill”

  2. 前置依赖——需要哪些文件、数据、工具

  3. 执行步骤——5-10 步标准流程

  4. 输出格式——交付物长什么样

  5. 失败处理——数据缺失、工具失败时怎么办

文件结构长这样：

skills/initiating-coverage/├── SKILL.md # 核心说明（触发时加载）├── references/ # 参考材料（按需读取）│ ├── comps-guide.md│ └── dcf-template.md└── scripts/ # 可执行脚本 ├── fetch_data.py └── render_chart.py

Skill 的关键机制是懒加载。system prompt 里只列名字和一句话说明，不载入完整内容。只有当模型判断”这个任务需要 XX skill”时，才用 Skill 工具调用，把对应的 SKILL.md 完整加载到上下文。

不调用 = 不加载，调用过 = 被缓存。这就是”不浪费上下文”的关键。

WorkBuddy 自带的 equity-research 专家包里有 17 个 Skill，覆盖了股票研究从首次覆盖到跟踪退出的完整生命周期。

五、MCP Tools 和 Connector Status：“能调” vs “现在能调”

MCP Tools 是外在能力连接器。它的命名规范是三级下划线：mcp____。

mcp__cls-mcp-server__QueryMetricmcp__cls-mcp-server__SearchLogmcp__ardot__create_designmcp__neodata__financial_search...

但很多人忽略了一个关键设计：MCP 工具在 system prompt 里列出来了，不等于实际可用。

Connector Status 才是”现在能不能用”的真实公告：

wecom 企业微信: connectedgithub GitHub: disconnectedfeishu 飞书: disconnectedneodata 金融数据: connected

这两个概念的区别很容易被忽略：

  • mcp__xxx__yyy → 我能调这些（能力清单）

  • connector-status → 现在我实际能调哪些（运行时状态）

就算 MCP 工具列在 deferred tools 里，如果 connector-status 标了 disconnected，调用时仍然会失败。所以模型在动手前，会先扫一眼状态公告——“既然飞书未连接，我建议改用企微 webhook 或邮件”——这就是 connector-status 在起作用。

还有一个容易被忽视的坑：新增 MCP 工具后，必须新开会话才能用。因为 tool 列表在会话开始时由 system prompt 注入，一旦锁定就不会动态新增。改 token 可能部分场景热加载，但稳妥做法一律是新开会话。

六、Sub-Agents：上下文隔离的秘密

当任务复杂、需要长链推理和多工具协作时，WorkBuddy 会派子 Agent 去干脏活。

Agent({ description: "复盘 3 个月前的隆基绿能多头逻辑", prompt: "详细指令...", subagent_type: "general-purpose"})

子 Agent 有三个核心价值：

  1. 避免主上下文污染。大模型的”注意力”是有限的——让它长时间处理大量工具输出，前面的内容会被挤出去。子 Agent 在独立窗口里折腾，主 Agent 只等结论。

  2. 任务并行。多个子 Agent 可以同时跑，互不干扰。

  3. 专业化。equity-research-expert 本身就是一种子 Agent。

最关键的设计约束：主 Agent 只看到子 Agent 的结论卡片，不看到它的思考过程。子 Agent 看不到主 Agent 的完整对话历史，也看不到其他子 Agent 的过程。回传的只是”压缩后的文本结论”。

这跟 Hermes 的 delegate_tool.py 的设计非常一致——上下文隔离，是并行架构能成立的前提条件。

七、Memory：三层记忆各自管什么事

专家模式里，记忆不是”一团东西”，而是严格分了三层：

层级存储位置作用域写入方
L1 Cloud Profile服务端全用户服务端自动
L2 User-level～/.workbuddy/MEMORY.md跨项目用户显式要求 / Agent 自动
L3 Workspace.workbuddy/memory/当前项目Agent 自动

L1 是服务端根据用户长期行为自动生成的画像，会话开始时注入，用户只读。

L2 是跨项目的长期记忆。比如”记住，我所有的 Python 脚本都用 3.13”——这种跨项目生效的个人习惯。

L3 是项目级工作日志。每日 YYYY-MM-DD.md 是 append-only，MEMORY.md 是凝练后的项目笔记。

L2 和 L3 的判断很简单：“我写 Python 用 3.13”→ L2，“本项目用 React 18 + TypeScript”→ L3。

八、Working Modes、Result Presentation、Automations：把专家能力产品化

这三个组件放在一起讲，因为它们共同定义了专家能力的产品化层。

Working Modes 是让用户主动控制模型的”动手边界”：

模式含义能力
Craft你说我做全能力
Plan想清楚再做只读 + 规划
Ask只说不动只读不写

用户在 UI 上切换，不是模型自决。Ask 模式下仍能查数据、读文件，只是不写不跑命令。这解决了”我以为你只是问问，结果你直接动手了”的信任问题。

Result Presentation 强制模型做完事情后把成品摆出来。核心规则是：

每个结果都用 present_files——不只是写文件，还要把文件”递”给用户。只展示新生成的成品，不展示中间产物。本地 HTML 自动开预览面板。

Automations 让专家能力脱离单次会话、定时执行。比如每天 8:30 自动出黄金报告，用户不需要主动找模型。

底层是 SQLite 数据库，支持 recurring（周期）和 once（一次性）两种调度。7 条铁律里最重要的一条：永远不要用 rm 删自动化，必须用 automation_update 的 delete 模式。

九、专家模式 vs 传统 Prompt：不只是量的差别

维度传统 Prompt Engineering专家模式（AI Harness）
长度单个 system prompt 几千字拆成 Rules + Expert + Skill + Tool + Memory
可复用复制粘贴整段marketplace 安装、版本管理
可扩展改 prompt 文本装新 skill、接新 MCP、加新 rule
可观察看不到执行skill 加载日志、MCP 调用日志、memory 写入日志
可组合单一大模型多个子 agent 协作 + 多 skill 串联
调试改 prompt 重试改 skill 改 rule 改 MCP，精确隔离
可分发难分享一个 plugin.json + 标准目录

一句话总结：

传统 prompt 是”一篇文章”，专家 harness 是”一个 IDE”——把模型当 CPU，把 Rules/Skill/MCP/Memory 当外设和软件，让”专家能力”成为可安装、可配置、可调试、可分发的软件包。

总结

  • 专家模式不是”写一段更好的 prompt”，而是把专家能力工程化成可安装的软件包——Rules、Skills、MCP Tools、Memory、Sub-Agents 各司其职。

  • Rules 是系统级宪法，Expert Prompt 是专家级身份——共用同一套 Rules，新增专家只需一份 Prompt。

  • Skill 不是单个工具，是可懒加载的工作流模板——不调用不加载，节省上下文窗口。

  • MCP Tools 的能力清单和 Connector Status 的运行时状态必须区分——“能调”不等于”现在能调”。

  • Sub-Agent 的核心价值是上下文隔离——主 Agent 只见结论不见过程，多个子 Agent 并行不互相污染。

  • 三层记忆各管各的作用域——云端画像、用户习惯、项目日志，不混在一起。

  • Working Modes + Result Presentation + Automations 构成产品化层——把”聊一次”变成”可重复使用的产品”。

AI 应用的”工业化拐点”已经来了。未来 3-5 年，所有领域专家 AI 都会长成这样——规则、技能、工具、记忆、交互范式各司其职，一个大模型作为统一推理引擎调度。

关注我，James 的成长日记，持续分享干货，帮你在 AI 时代少走弯路。

内容效果不满意？点此反馈

输入关键词开始搜索