每日了解一个智能体 ------ WorkBuddy：当 Agent 开始接住整条工作流
一、先用一个运维场景建立直觉
先看我们这行最典型的一件重复劳动：季度安全运营报告。
我做过一份某银行邮件网关的 Q2 报告：9 章、3 张表、20 张截图。它的真实工作流长这样：
① 登录设备导出告警数据（几个界面、几种格式）
│
② 从邮件网关 / 防毒墙 / 沙箱各拉一份原始数据
│
③ 手工统计：TOP5 告警类型、趋势环比、处置率
│
④ 挑代表性截图，逐张裁、逐张编号
│
⑤ 按上季度的模板，把数据填进 Word
│
⑥ 调格式：标题层级、表格表头、页眉页脚、图注
│
⑦ 自查：数据口径是否自洽、章节编号是否断档
│
⑧ 导出 PDF，发客户前三代工具分别能帮到哪一步：
| 工具 | 能帮到 | 卡在哪 |
|---|---|---|
| 聊天式大模型 | 帮你写第 ⑤ 步的文字 | 数据得你喂，格式得 you 调，图得你贴。它只碰到了中间一环。 |
| 编码 Agent（Codex 那类） | 帮你写脚本处理第 ③ 步 | 它活在代码仓库里，登不了你的设备，看不懂你的 Word 模板 |
| 通用工作型 Agent | ① → ⑧ 全程接 | 前提是：它能拿到你的数据、记得你的规矩、会用你的工具 |
差别在哪？ 前两代缺的都是同一件东西------接入。
聊天模型是孤岛 ：你搬数据进去，它把文字搬出来。
编码 Agent 是车间 ：它能自证代码对不对，但车间里没有你的业务系统。
通用工作型 Agent 要解决的，是把孤岛和车间连成一条流水线。
而"连起来"这件事，靠的不是模型更聪明，靠的是四样工程件：技能、连接器、记忆、子代理。
二、整体架构（先看全貌）
┌──────────────────────────────────────────────────────────────────┐
│ 用户（一个岗位角色） │
│ 安全运维 / 售后交付 / 报告编写 / 数据分析 │
└────────────────────────────────┬─────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ ① 能力装配层：按需加载（这是最核心的设计） │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 技能 Skills │ │ 专家 Experts│ │ 连接器/MCP │ │
│ │ · 用户级 │ │ · 100+ 领域 │ │ · 腾讯文档 │ │
│ │ · 项目级 │ │ · 方法论注入 │ │ · 企业微信 │ │
│ │ · 触发词命中 │ │ · 团队协作 │ │ · 邮件/IM │ │
│ │ 才加载 │ │ │ │ · 自定义 MCP │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ └─────────────────┼─────────────────┘ │
│ ▼ │
│ ② 工具层（延迟加载 ToolSearch） │
│ 几十上百个工具，用到才载入 schema │
└────────────────────────────────┬─────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ ③ 执行层 │
│ · 本地文件系统（读写/编辑/命令） │
│ · 云服务（数据库 / 存储 / 认证 / 免密钥调 LLM） │
│ · 多模态生成（图片 / 视频 / 3D） │
│ · 可视化（内联 SVG / HTML 图表、交互组件） │
│ · 文件交付（Word / Excel / PPT / PDF 生成与就地编辑） │
└────────────────────────────────┬─────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ ④ 协作层：子代理（上下文隔离 + 并行） │
│ 主 Agent 派活 → 子 Agent 各自跑 → 只回传结论 │
│ （探索 / 规划 / 表格 / 文档写作 / 排版 / 格式转换 ...） │
└────────────────────────────────┬─────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ ⑤ 记忆层（三层，这是它区别于"一次性聊天"的关键） │
│ · 云端记忆：跨会话检索历史讨论 │
│ · 用户级 MEMORY.md：跨项目的长期规矩 │
│ · 工作区 memory/YYYY-MM-DD.md：项目日志（只追加） │
└────────────────────────────────┬─────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ ⑥ 常驻层：自动化 + 发布 │
│ · 定时任务（RRULE：每天/每周/每月，或一次性） │
│ · 站点与小程序部署上线 │
└──────────────────────────────────────────────────────────────────┘和前两篇对比一下，你就能看出定位差异：
| 千问（框架层） | Codex（编码层） | WorkBuddy（工作层） | |
|---|---|---|---|
| 核心命题 | 模型怎么调工具 | 怎么自证代码对不对 | 怎么接住整条业务流 |
| 主场 | 一个对话 | 一个代码仓库 | 一个岗位 |
| 关键工程件 | Function Calling / ReAct | 沙箱 / 验证环 | 技能 / 连接器 / 记忆 / 子代理 |
| 衡量标准 | 调用成功率 | 测试通过率 | 交付物能不能直接用 |
三、逐层拆解：六个真正有用的设计
3.1 技能系统：为什么要"按需加载"而不是"一次喂全"
这是整个架构里我最想讲的一个设计。
朴素做法 ：把所有能力写成一大段系统提示词，一股脑塞进上下文。
后果：上下文被背景知识吃掉大半，真正留给"当前这件事"的空间所剩无几；而且能力一多，模型会"选择困难"------该用 A 技能的时候用了 B。
WorkBuddy 的做法 ：技能是文件，不是提示词。
~/.workbuddy/skills/ ← 用户级：跨项目通用
└── 我的技能包/
├── SKILL.md ← 触发条件 + 执行步骤
├── scripts/ ← 技能可调用的脚本
└── references/ ← 参考资料，用到才读
{workspace}/.workbuddy/skills/ ← 项目级：团队共享加载时机由"触发词"决定 ------只有当用户意图命中某个技能的描述时，那份 SKILL.md 才会被读进上下文。
用户说："帮我把这份 PDF 整理成 Word"
│
▼
扫描已安装技能的描述（只读 description，很轻量）
│
▼
命中 → 文档处理技能
│
▼
加载 SKILL.md 全文 → 按其中的步骤执行
│
▼
过程中需要细节 → 再读 references/ 里的具体文件这个三段式（描述 → 主文件 → 参考资料）是标准的"渐进式披露" ，也是上下文经济的核心手段：永远只把"此刻需要的"放进上下文。
对我们的启发很直接 ：这跟我们做设备故障处置手册是一个道理。
你不会把 200 页手册一次性念给新人听，你会先给一张"什么症状对应哪一章"的索引表。
技能系统的
description字段，就是那张索引表。而索引表写得准不准，决定了整个系统会不会用错技能。
3.2 专家：把"方法论"而不是"知识"注入进来
技能解决的是"怎么做一件事"，专家解决的是"用谁的标准做"。
比如同一个"漏洞分析报告"：
- 用安服工程师的专家视角 → 重攻击链、重 IOC、重处置时效
- 用合规审计的专家视角 → 重等保条款映射、重证据链完整性
- 用管理层汇报的专家视角 → 重风险量化、重业务影响、弱化技术细节
同一份素材，三种产出。专家包里装的是判断标准与取舍偏好，这比"知识"稀缺得多。
这里有个很容易被低估的点：一个人真正值钱的不是"会做"，是"知道什么情况下该怎么做、做到什么程度算够"。 专家机制本质上是在尝试把这部分固化下来。
3.3 连接器与 MCP：把手伸进真实业务系统
这一层决定了 Agent 是"能聊"还是"能干"。
┌──────────────┐
│ Agent │
└──────┬───────┘
│ 统一协议
▼
┌──────────────────────────────────────┐
│ 连接器 / MCP Server │
├──────────────────────────────────────┤
│ · 腾讯文档 / 企业微信文档 │
│ · 即时通讯（读会话、发消息） │
│ · 智能体邮箱（收发邮件、附件） │
│ · 知识库 / 网盘 / 会议 │
│ · 工单 / 代码仓库 / 项目管理系统 │
│ · 自定义 MCP server（你自己写的） │
└──────────────────────────────────────┘MCP（Model Context Protocol）的意义，是把"接一个外部系统"从定制开发变成配一段 JSON。 自定义 MCP 写在 ~/.workbuddy/mcp.json 里，加个 command + args + env 就能接入一个新的内部系统。
对我们这行的实际价值：想象一下把下面这些接进来------
- 堡垒机的操作审计日志
- 工单系统的待办列表
- 资产台账（CMDB）
- 漏洞扫描器的结果库
接上之后，"帮我看看这个季度哪几台设备还没打 XX 补丁"就不再是"你把 Excel 传给我"，而是它自己去查、自己去对。
但这里有一条红线必须说清楚 ：客户环境数据（内网拓扑、真实 IP、账号口令、告警原始日志）禁止直接送进公网大模型 。
我在自己的长期记忆里就写死了这条规矩，每次会话自动加载。
接入能力越强，这条红线越要提前写成机器可读的约束，而不是靠临场记得。
3.4 三层记忆：它为什么记得住你的规矩
这是 WorkBuddy 区别于"每次都是新对话"的产品最本质的地方。
| 层 | 存什么 | 作用域 | 特点 |
|---|---|---|---|
| 云端记忆 | 历史会话、过往决策 | 跨会话检索 | 服务端排序检索，适合"上次那个方案我们怎么定的" |
用户级 MEMORY.md |
长期偏好、红线、既定事实 | 跨所有项目 | 人工可编辑，写进去就是硬约束 |
工作区 memory/YYYY-MM-DD.md |
项目日志 | 当前项目 | 只追加不覆盖，形成时间线 |
这三层不是冗余，是三种完全不同的用途：
- 云端记忆解决"我记不清是哪次聊的了"------检索式。
- 用户级 MEMORY.md 解决"这件事每次都要说一遍"------声明式。
- 工作区日志 解决"这个项目走到哪一步了"------时间线式。
举个真实的用法（这是我自己记忆文件里的一条）：
markdown
## 红线（必须提醒）
- 客户环境数据（内网拓扑、真实 IP、账号口令、告警原始日志）
禁止上传公网 AI，需脱敏或本地处理。
- AI 只做结构与语言层，数据、结论、口径必须真实，
不得让 AI 编造安全数据。这两行字，每次新会话都会被自动读进来。 它不是一个"我希望 AI 记住"的愿望，是一条写死在配置里、每次都生效的约束。
我在第 2 篇讲 Codex 时提过
AGENTS.md------把团队隐性约定变成 Agent 可读的显式上下文。这三层记忆是同一个思路，只是把作用域从"一个仓库"扩到了"一个岗位"。
工作区日志为什么设计成"只追加"？
因为它要的是可追溯的时间线 ，不是一份状态快照。三个月后回看，你能看到"10-28 决定用方案 A，10-29 发现数据口径不一致改了口径 B"------决策的来龙去脉比结论本身更值钱。这也是我做事故复盘时最看重的东西。
3.5 子代理：上下文隔离 + 并行
长任务最大的敌人不是模型不够聪明，是上下文污染------跑到后面，前面塞进去的中间结果把窗口挤满了，模型开始丢约束。
子代理的解法是：派一个独立的上下文去干活，只把结论带回来。
主 Agent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│探索子代理│ │规划子代理│ │文档子代理│
│（只读） │ │（设计） │ │（写作） │
│ 读 50 个 │ │ 出方案 │ │ 出初稿 │
│ 文件 │ │ │ │ │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└────────────┼────────────┘
▼ 【只回传结论，不回传过程】
主 Agent 汇总关键点在"只回传结论" ：探索子代理读了 50 个文件、消耗了几万 token，但主上下文里只多出几百字的摘要。这跟 Codex 的"上下文自动压缩"是同一类工程手段，只是粒度不同------一个是压缩，一个是隔离。
子代理还有几种典型分工（都是真实存在的角色）：
| 类型 | 干什么 | 什么时候用 |
|---|---|---|
| Explore | 快速摸清代码库/文件结构 | 面对陌生项目时，先派它去 |
| Plan | 设计实施方案 | 动手前的方案评审 |
| 表格代理 | 读写分析 Excel/CSV | 数据处理类任务 |
| 文档三段式 | 写作 → 排版 → 格式转换 | 正式文档交付 |
| general-purpose | 通用多步执行 | 复杂长任务 |
3.6 自动化与发布：从"一次对话"到"常驻流程"
前五层解决的都是"这一次对话能干多好"。第六层解决的是"我不在的时候它能不能自己跑"。
一次性执行：2026-11-05 14:30 提醒我提交季度报告
周期执行： FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0
→ 每周一 09:00
→ 【拉取上周告警数据 → 多周期对比 → 生成报告 → 推送】注意自动化提示词的写法原则（这是踩过坑的经验）：
❌ 错：
"每天早上九点，拉取 A 股开盘数据并生成报告"✅ 对：
"拉取 A 股开盘数据并生成报告"------ 调度信息写在调度字段里，不写在提示词里。未来执行时看不到你当前的对话，提示词必须自包含：公司名、文件路径、指标口径、偏好，全都要写进去。
这条原则值得单独记 ：凡是要"以后再跑"的东西，提示词必须能脱离上下文独立成立。
配套的发布能力（站点部署、小程序托管）则把"生成一个网页"推进到"这个网页真的在线上跑着"------从产出物到服务。
四、一个真实跑通的案例：把季度报告做成流水线
前面都是架构，这一节讲我实际跑过的一条流水线。它正好把上面几层设计串起来了。
任务：把一份 PDF 版的事故分析报告，重做成一份带正式排版的 Word 交付文档。
三段式流水线：
┌────────────────────────────────────────────────┐
│ S1 doc-writer 创作 ：产 Markdown 正文 │
│ ↓ 中间产物，不是交付物 │
├────────────────────────────────────────────────┤
│ S2 doc-formatter 排版 ：产 HTML 版式 │
│ ↓ 选模板 / 仿参考文档风格 │
├────────────────────────────────────────────────┤
│ S3 doc-converter 转换 ：HTML → DOCX │
│ ↓ 强制打开预览 │
└────────────────────────────────────────────────┘为什么要拆三段？ 因为这三件事的失败模式完全不同：
| 阶段 | 失败模式 | 谁该负责 |
|---|---|---|
| 创作 | 内容缺项、逻辑不通、口径矛盾 | 内容与领域知识 |
| 排版 | 标题层级乱、表格无表头、间距不一致 | 版式规范 |
| 转换 | 图片丢失、字体替换、分页错乱 | 工程实现 |
合成一步做，出问题时你根本分不清是哪一层错了。拆开之后，每一段都能单独重跑、单独验收。 这跟我们做变更要拆步骤、每步验证是一个道理。
踩过的三个坑（真实记录，很有代表性）：
坑一：转换后图片全丢了。
原因：转换服务不读本地相对路径的图片。解决办法是把图片转成 base64 data URI 内嵌进 HTML。8.45 MB 的 HTML，转换后图片全部落地。
坑二：排版评分只有 45 分。
自动评审指出三类问题：25 张表格缺 <thead>/<tbody>；间距用了裸值（1.5em）没走 CSS 变量；缺执行摘要区。注意这些都是"机器可判定"的问题------这正是"能自证"的价值：它不是"我觉得不好看"，是逐条可检查。
坑三：用户删了几章之后，编号断档了。
5.5 应该变 5.3，6.4/6.6 应该变 6.2/6.3，还有汇总表里的序号 1/2/3/5------这个用文本替换改不到，因为它在表格里，要用专门的表格写入工具。
这三个坑有个共同点：都是"看起来完成了，实际交付不了"的问题。
生成 Word 容易，生成一份能直接发给客户的 Word 难。中间那段距离，全靠工程细节填。
这跟第 2 篇 Codex 的结论是同一句："能演示"和"能交付"之间的距离，就是全部工程量。
五、运维人最该从这里抄走的三件事
5.1 把重复的交付物，做成"技能"而不是"模板"
模板是死的，技能是活的。区别在哪？
| 传统模板 | 技能 | |
|---|---|---|
| 形态 | 一个 .docx 文件 | 一个目录：SKILL.md + scripts/ + references/ |
| 怎么用 | 人去填空 | Agent 按步骤执行，脚本自动干活 |
| 知识放哪 | 全塞在模板里 | 分层：主文件放流程，参考资料按需读 |
| 能不能校验 | 不能 | 能（脚本 + 自检清单） |
一个"季度安全运营报告"技能包大概长这样：
quarterly-security-report/
├── SKILL.md ← 触发条件 + 8 个步骤
├── scripts/
│ ├── collect_alerts.py ← 从导出文件抽取告警数据
│ ├── check_consistency.py ← 口径自洽检查（数字加起来对不对）
│ └── render_charts.py ← 生成趋势图
├── references/
│ ├── 章节结构规范.md
│ ├── 术语与口径表.md ← "攻击次数"到底是什么口径
│ └── 脱敏规则.md ← 哪些字段必须脱敏
└── templates/
└── QBR-template.docx口径表和脱敏规则这两份参考资料，是最值钱的部分。 它们承载的是"我们单位对这件事的标准"，而不是"AI 对这件事的理解"。
5.2 把红线写进记忆，而不是写进每次的提示词
我自己的 MEMORY.md 里有两条，前面贴过。再强调一遍为什么它必须放在记忆里：
❌ 每次对话开头提醒自己"这次别把客户 IP 发出去"
→ 会忘，尤其在长任务的第 20 轮
✅ 写进用户级 MEMORY.md
→ 每次会话自动加载，不依赖你的记性，也不依赖上下文还剩多少判断标准很简单：凡是"每次都要说一遍"的规矩，就该写进长期记忆。 脱敏规则、报告口径、客户命名规范、交付物存放路径------这些都属于这一类。
5.3 长任务拆子代理，别硬扛
一条硬经验：单次对话里塞超过 15～20 个工具调用结果，后面的质量会明显下降。 这时候该做的不是"精简提示词"，是拆出子代理。
主 Agent：定目标、派活、验收
│
├── 子代理 A：去摸清 30 台设备的配置现状（只读，探索）
├── 子代理 B：对照基线，算出偏差清单
└── 子代理 C：把偏差清单写成报告初稿每个子代理在自己的上下文 里干活，只把结论带回来。这跟我们做大型变更要分组实施、各组只汇报结果是同一个道理。