xiaode console · 工作流控制
控
小德中控台
08:00
启动 Mode A 日报
OpenClaw · 在线
已创建任务队列,researcher 正在采集风电资讯;完成后在中控台候选区等待审批。
researcher · mode_a_radar
→ # 调用 mode_a_radar skill
→ tavily.search("SCADA fault 2026")
✓ 10 results · L2 期刊 4 / L3 媒体 6
→ tavily.search("FMCW lidar blade")
✓ 8 results · 国际源 7
→ scoring · 命中关键词 → 1-5★ 评级
✓ 5★ 4 · 4★ 11 · 3★ 8
→ # 输出 JSON · 国际源 91%
console · 候选选题审批
📡 Mode A · 2026-04-24
23 条 · 国际源 91% · 5★ 4 / 4★ 11 / 3★ 8
🔥 5★ 推荐
1.ONYX launches ecoBLADE blade monitoring system
L3 · ★★★★★ · 04-21
2.CEA-DETR for Blade Defect Detection
L2 · ★★★★★ · 04-22
3.A digital twin for offshore wind energy
L2 · ★★★★★ · 04-22
writer · 微信兼容 HTML
<div style="bg: #4a5a6a">
<div style="padding: 32">
<h2>风电科技资讯</h2>
<p>ONYX 推出叶片监测
</div>
</div>
// ✓ 推送公众号草稿箱
AI Agent Portfolio · Xiaode Console · BlueWhale Voice Agent

能进真实业务的 AI Agent 作品集

我是刘沛呈。这里记录两个后期更完整的项目:为雅德士内容生产线做的 小德中控台,以及面向园区门岗的蓝鲸语音助手。 重点不是“会调用模型”,而是把 agent 接到审批、数据、电话、通知、排障和验证链路里。

看项目总览→ peteliu0522@gmail.com
SCROLL
02 RESULTS

两个 AI Agent 项目的核心证据

这个作品集现在以“小德中控台”和“蓝鲸语音助手”为主线:一个证明多 Agent 能进入内容生产流程,另一个证明语音 agent 能接真实电话、写入后端并通知门卫。

0
完整业务场景项目
小德内容运营中控台 + 蓝鲸园区访客语音登记
0%
小德内容生产耗时压缩
单篇成稿:近 8 小时人工 → 30 分钟选题与审核
0+
小德已发布成品文章
2026 年至今发布到雅德士公众号,并带来央企主动询盘
0s
蓝鲸语音登记目标
围绕 25 秒目标设计短轮次 prompt、来电号码复用和熟客路径
"
沛呈不是科班出身,但他能从一个真实业务问题出发,自己摸索出整套技术方案并坚持迭代到稳定能用——这份独立做事的能力,放在小公司或者创业团队都很需要。

我们是一家做风电叶片检测的小公司,公众号一直靠我自己抽时间打理。沛呈来了之后,花了几周时间设计了一套用 AI 多 Agent 协同跑的内容工作流——从搜国际前沿资讯,到筛选,到改写排版,再到推到草稿箱,基本不需要我动手。我每天大约 30 分钟选题和审核就能完成过去要接近一天的工作。

更重要的是,产出的文章专业度比我自己写得高。最近一篇关于风电检测的文章,有华能集团云南分公司的负责人主动打电话来咨询业务合作——这种来自大型央企的主动询盘,是我们公司这几年从来没有过的。

沛呈不是科班出身,但他能从一个真实业务问题出发,自己摸索出整套技术方案并坚持迭代到稳定能用,这份独立做事的能力,放在小公司或者创业团队都很需要。

刘杰  ·  北京雅德士工程技术咨询服务有限公司创始人
03 OPENCLAW CONSOLE

后来我把“小德”升级成可运营的中控台

第一阶段解决的是“能不能自动生成一篇公众号文章”。真正上线后,问题变成了另一组更像产品和运维的问题: 今天跑到哪一步了?候选在哪里选?哪篇论文可以进 Mode B?OpenClaw 网关是不是活着?备用通知有没有发出? 失败任务怎么重试,产物保存在哪里,数据库字段缺失怎么修?

所以我做了一个本地 React + Express 中控台,把内容生产链路从“命令行 + 文件夹状态 + 分散消息”收束成一个老板和管理员都能用的后台。 它让小德从一个会写稿的 agent,变成一套能被人监督、审批、排障和持续运行的业务系统。

Mode A/B 工作流控制99% 操作在这里完成:启动日报、批准论文速览、查看候选列表、提交选题并追踪写稿阶段。
内容数据库治理已发库、备选池、论文池统一检索,支持查重、字段修复、SQLite/JSON 同步。
OpenClaw 运维面板检查 Gateway、RPC、通知通道、任务状态和网络访问入口,必要时触发重启。
失败任务自修复识别假运行、日期错乱、HTML 产物缺失和发布失败,把修复入口留在任务表内。
小德中控台真实界面截图
01Twilio Entry

访客拨打园区公告电话

门岗不用安装新系统,访客只需要拨打公开电话。Twilio 把真实来电转成可处理的 webhook。

real phone call
☎
蓝鲸园区访客登记 021-8999-6630
Incoming Call /twilio/elevenlabs-entry
phoneTwiliowebhook
01 / 06
Drag / Swipe
04 BLUEWHALE VOICE AGENT

后来我又做了蓝鲸园区访客车辆语音登记系统

蓝鲸解决的是门岗登记场景:访客拨打公告电话后,语音智能体自然采集车牌号、来访单位、手机号和事由; FastAPI 后端把对话结果变成结构化记录,再推送企业微信给门卫确认放行。

我没有把业务逻辑全部交给语音平台托管。最终主链路是 Twilio 电话入口 + ElevenLabs Conversational AI + 自建 FastAPI 工具接口 + 企业微信通知/查询助手;Cloudflare Tunnel 负责本地演示公网回调,Cloudflare Worker + Neon 作为后续 serverless 迁移路径。

电话到 Agent 的接入Twilio webhook 进入 ElevenLabs,并把来电号码、CallSid 等动态变量注入本次会话。
确定性后端工具Agent 负责对话和意图提取,FastAPI 负责字段校验、熟客复用、记录持久化和错误处理。
门卫工作流闭环登记完成后推送企业微信 markdown 卡片;门卫还能通过企业微信机器人查询最新访客、车牌、手机号和统计。
可提交的工程材料README、OpenSpec/SDD、失败迭代、最终验证、测试和 CI 都整理为中文记录,方便答辩和复盘。
稳定演示链路: Twilio 电话入口 -> ElevenLabs Conversational AI -> FastAPI 后端工具 -> 企业微信门卫通知/查询。
05 CONTEXT

一家做风电叶片检测的技术型公司,需要每天发公众号

以下是这套工作流要解决的真实业务问题——谁在用、为什么需要、原本怎么做、瓶颈在哪。

业务现状

雅德士:风电叶片检测领域的技术型公司

2003 年成立,前身为中丹合资企业,专注风电技术服务 22 年。FMCW + OFDR 双技术平台,多项国家发明专利。

  • 386 台 累计完成风机叶片检测与矫正
  • 80% 营收用于研发投入
  • 22 年 行业专注时长
运营痛点

公众号是行业询盘的主要入口,但内容靠老板手动维护

原工作流由老板(刘杰)一人完成:搜索国际资讯 → 翻译筛选 → 改写排版 → 推送草稿。

  • 近 8h 单篇成稿耗时
  • 波动大 质量受当日精力影响
  • 不可扩展 老板时间是硬瓶颈
技术机会

多 Agent 系统可拆解为搜索 + 评估 + 改写流水线

核心判断:内容生产可分解为三个相对独立的环节,每个环节都能用 LLM + 工具调用替代人工。

  • OpenClaw 类 Claude Code 的 file-based agent 框架
  • DeepSeek V4 Pro 中文性能足够,成本可控
  • 小德中控台 作为 99% 操作入口;飞书 Bot 只保留备用选题与任务完成通知
交付目标

把"近 8 小时成稿"压缩到"30 分钟审核"

系统替代手动搜索、筛选、改写、排版四个环节;老板主要在中控台完成启动、选题确认、进度查看与终审,飞书仅在需要时做备用选题和完成通知。

  • 0 编造 所有引用强制可验证
  • 对齐业务 资讯方向匹配公司主营
  • 稳定可用 每日跑批不依赖人工干预
04 BUSINESS CONSTRAINTS

六类业务约束的工程化实现

信息源、时效、方向配比、Mode B 规则、写作风格、平台兼容—— 六类业务约束分别由对应的 skill 文件、评分函数和后处理 check 实现, 确保系统每日稳定输出。

悬停任意卡片查看完整实现。

A
INFO SOURCE

对每条 URL 进行分级评分与黑名单过滤

6 层信源金字塔 · 国际源 ≥ 50% · 黑名单 5 类
约束

tavily 搜出来的每条 URL 按 6 层金字塔分级——L1 同行评议 / L2 行业期刊 / L3 国际工业媒体 / L4 制造商官方 / L5 学位论文 / L6 其他可验证。每天的资讯里国际源占比不低于 50%。黑名单覆盖百度百科、个人博客、电商页面、聚合转载。

实现

researcher 工作空间的 scoring.md 通过关键词加权对每条结果打分;URL 域名匹配白/黑名单。mode_a_radar skill 在 evaluate 阶段剔除 L6 之外的可疑源。

B
TIME WINDOW

按发布时间窗口过滤素材

Mode A 优先 3 天 · 最多 7 天  ·  Mode B 优先 6 月 · 最多 12 月
约束

Mode A 资讯优先 3 天内、最多 7 天;Mode B OA 论文优先 6 个月内、最多 12 个月;超出窗口的素材在 evaluate 阶段剔除。

实现

search query 自动附加日期 filter;evaluate.md 给过期项扣减 freshness_score;最终 select 阶段一票否决超期项。

C
DOMAIN MIX

4 类资讯方向按固定比例分布

故障 40% · 检测 25% · 运维 20% · 政策 15%
约束

资讯方向分布与雅德士业务重心对齐——故障诊断 40%、叶片检测 25%、运维优化 20%、政策市场 15%。

实现

researcher 在拆 query 时按比例分散关键词;evaluate 阶段统计 4 类计数;select 时强制按配比筛选,缺失方向触发补搜。

D
MODE B RULES

Mode B 输出由 8 条硬规则约束

8 条硬规则 · OA 期刊 · 5 个固定 PART
约束

标题原文直译;OVERVIEW 客观;5 个 PART 只做 summarize + 翻译;结构对应原章节;KEY POINTS 客观;编者讨论顶部声明立场;编者讨论必须基于原文;严禁输出原文之外的任何内容。

实现

writer 工作空间内独立 MODE_B_RULES.md 文件,写作前强制加载;输出后通过 verify 步骤反查每段对应原文位置。

E
TONE & VOICE

营销词过滤与决策点占位机制

营销词黑名单 7 个 · 决策点 placeholder
约束

营销词黑名单——震惊 / 重磅 / 革命性 / 突破 / 颠覆 / 领跑 / 重新定义;保持专业克制语气;所有需要主观判断的位置以 placeholder 保留,不代替决策。

实现

MODE_A_RULES.md / MODE_B_RULES.md 固化风格规则;writer 后处理执行 banned_word check;待决策位置输出 [PENDING_OWNER_DECISION] 占位符。

F
PLATFORM QUIRKS

微信 HTML 兼容与模型 API 限制处理

微信 HTML 白名单 · 8K 截断防护 · IP 白名单
约束

微信公众号 HTML 不支持外部 CSS 与部分标签,style 必须内联;DeepSeek API 仅对白名单 IP 开放,经 VPN 调用不可用;DeepSeek 单次输出超过 8K 会被截断;备用飞书通知存在长度限制。

实现

writer_task.md 内嵌微信兼容标签白名单;超长输出分块生成并拼接;服务器通过专线接入,不使用 VPN;完成通知按段拆发,不再承载主流程审批。

06 ARCHITECTURE

三个 agent 工作空间 + 中控台 + 模型/工具对称协同

系统由小德中控台、三个对称的 agent 工作空间(xiaode / researcher / writer)、外部模型与搜索 API 组成。中控台承担 99% 的启动、审批、追踪和运维操作;飞书只作为备用选题入口与任务完成通知。

启动 / 审批 / 状态回写 派单 ↕ 回结果 派单 ↕ 回结果 推送草稿 USER INTERFACE 小德中控台 启动 · 选题 · 追踪 · 运维 ORCHESTRATOR · HUB 小德 主调度 · 派单 · 汇总 · 推送 workspace: xiaode/ 所有 agent 通信经此 AGENT 01 · 独立 researcher 搜索 · 评分 · 配比 mode_a_radar.md scoring.md · evaluate.md calls: Tavily + DeepSeek AGENT 02 · 独立 writer 改写 · 微信兼容 HTML 生成 MODE_A_RULES.md MODE_B_RULES.md calls: DeepSeek EXTERNAL · SEARCH API Tavily API 网络搜索 · 多源采集 EXTERNAL · LLM API DeepSeek V4 Pro chat / 1M ctx · IP 白名单 FINAL OUTPUT 微信公众号 草稿箱 · 兼容 HTML
Hub / 最终输出
独立 Agent / 外部 API
外部边界 (用户接口 / 推送)
内部 Agent 通信
API 调用
SEQUENCE · 单次跑批的时序流程
  1. 01 老板在小德中控台点击“启动 Mode A 日报”,系统创建任务并交给小德。
  2. 02 小德派搜索任务给 researcher,researcher 调用 Tavily + DeepSeek 搜索打分,回结果给小德。
  3. 03 小德将候选整理为中控台候选列表,等待老板在网页端筛选。
  4. 04 老板在中控台提交选题;飞书只在备用场景同步候选摘要。
  5. 05 小德对选定项做完整内容爬取,把素材整理后派给 writer。
  6. 06 writer 调用 DeepSeek 改写,生成微信兼容 HTML,回稿给小德。
  7. 07 小德保存 HTML/桌面产物并更新发布中心;飞书仅发送任务完成通知。
07 TECH DECISIONS

五个关键技术决策

每个决策都对应具体的取舍场景与技术理由,以下是项目中影响最大的五项。

01

Agent 框架选 OpenClaw 而非 LangChain

OpenClaw  vs  LangChain

OpenClaw 是类 Claude Code 的 file-based agent 框架,skill 直接是 Markdown 文件,可独立编辑、diff、版本控制。LangChain 的 prompt template 与 chain 结构在多 agent 场景下调试成本高,迭代速度慢。.md 即 skill 的设计也便于交付给非工程角色协同维护。

02

模型选 DeepSeek 而非 GPT-4

DeepSeek V4 Pro  vs  GPT-4 / Claude

中文风电技术文献处理上 DeepSeek 表现充分,单 token 成本约为 GPT-4 的 1/20,适合每日跑批的高频调用。国内 IP 白名单稳定不需 VPN,与雅德士服务器网络环境兼容。Mode B 论文速读对长上下文的需求由 DeepSeek V4 Pro 的 100 万 token 上下文窗口满足。

03

三个 workspace 对称设计

对称分工  vs  单 agent 大脑

xiaode 主调度、researcher 负责搜索评分、writer 负责生成排版。每个 workspace 有独立 skill 集与上下文,故障隔离清晰。某个环节出错可单独重跑而不影响整体。三者通过文件交换(JSON)通信,无内存依赖。

04

display_no 取代原 rank 字段

1-N 连续编号  vs  跳跃式 rank

v2.4 引入。原 rank 字段允许跳跃(1, 3, 7...),大模型在多轮对话中容易混淆"第几条"。改用 display_no 强制 1-N 连续,并配合 display-map.json 反查 rank,既保证人机沟通的稳定性,又保留原始评分顺序。

05

微信 HTML 兼容白名单刻进 writer_task.md

标签白名单 + style 内联  vs  外部 CSS / 全 HTML 集合

微信公众号编辑器对外部 CSS、特定标签、attribute 都有限制,普通 HTML 推送进去渲染会变形或丢内容。在 writer 的 skill 文件里硬编码兼容白名单(允许的标签集 + style 必须 inline),以及若干已验证的兼容写法模板。writer 输出严格按这些约束生成,绕过运行时校验,直接保证草稿箱可渲染。

08 IN PRODUCTION

系统每日运行的关键节点

以下是从生产链路整理的 6 个关键节点视图——从中控台启动、候选审批到公众号草稿箱推送,完整链路可追溯。

XIAODE CONSOLE · TASK QUEUE
Mode A 日报任务运行中
researcher 派单采集中
候选区等待审批自动回写
Gateway OK RPC OK 日志同步
STEP 01
中控台启动 · researcher 派单
老板在中控台启动 Mode A 日报,小德接单并派 researcher 搜索。cron 自动触发或手动触发均支持。
researcher 返回 + JSON 校验 + URL 抽查
STEP 02
researcher 返回 · JSON + URL 双重校验
researcher 完成搜索后,小德先做 Step 2 质量判定——验证 JSON 完整性、抽查 URL 真实性,过滤伪源后才进入候选区。
CANDIDATE REVIEW · MODE A
01SCADA fault detection update5★
02FMCW lidar blade inspection5★
03Offshore wind digital twin4★
23 条候选 · 国际源 91%提交选题
STEP 03
候选选题进入中控台审批
小德把候选按 5★ / 4★ / 3★ 分级,标注信源等级(L1-L6)与发布日期,展示在中控台候选区供老板选题;飞书只做备用摘要。
SELECTION MAP · DISPLAY NO
display_no: 1, 3, 5, 10已提交
original_rank: 4, 9, 12, 21已反查
writer_task.md已生成
审批记录写入 SQLite派给 writer
STEP 04
老板选题 · display_no 反查 rank
老板在中控台提交"选第 N、N、N 条",小德通过 display_map 反查原始 rank(v2.4 关键设计),将选定项派给 writer。
PUBLISH CENTER · OUTPUTS
微信兼容 HTML已生成
公众号草稿箱已推送
任务完成通知已发送
2026-04-24_mode_a.html2,800 字 desktop artifact已保存
STEP 05
writer 完稿 · 推送公众号草稿箱
writer 生成微信兼容 HTML 后小德推送至公众号草稿箱,中控台更新发布中心;飞书仅发送完成通知。
雅德士技术咨询服务公众号主页 · 9 篇原创 · 471 阅读 · 央企询盘文章置顶
STEP 06
公众号已发布成品
老板终审后发布。截至当前累计 23+ 篇,置顶文章带来华能集团云南分公司主动询盘
SHOWCASE · 两种成品模板

系统输出的实际排版细节

小德每日产出两种成品类型——Mode A 行业日报(每天 10 条精选)与 Mode B 论文速览(OA 期刊深度解读)。两套模板的排版规则均刻在 writer 工作空间的 RULES.md 文件中,严格按约束 D-F 执行。

Mode A 行业日报排版,Editor's Note + 10 条精选 + 4 类方向配比
MODE A YARDCE · DAILY BRIEF
每日行业速览

10 条精选,Editor's Note 提要 + 4 类方向配比 + 来源等级 L1-L6 标注。当日发布字数约 2,800,完整守约束 A-E。

Mode B 论文速览排版,DEEP READ + OVERVIEW + 5 PARTS 结构
MODE B YARDCE · DEEP READ
论文速览 · 深度解读

OA 期刊深度解读,Title 原文直译 + Overview + 5 PARTS + Editor's Discussion + Key Points。8 条硬规则严格执行,0 编造。

09 CHANGELOG

从 v1.0 到 v2.4 的关键变更

每次迭代对应一个真实业务问题或技术瓶颈。以下是项目从原型到当前生产版本的演进路径。

v1.0 2025-Q4

单 agent 原型 · 命令行 polling 模式

最初的单 agent 实现,直接在终端跑搜索 + 改写。验证了 LLM + Tavily 组合可行,但人工启动与无状态运行无法满足每日跑批需求。

v1.5 2026-01

researcher / writer 拆分

将搜索-评估和改写-排版拆为两个独立 workspace。引入 scoring.md 与 evaluate.md 评分函数,为后续多约束工程化奠定基础。

v2.0 2026-02

小德主调度 · 备用通知接入

新增 xiaode 主调度 workspace。早期用飞书快速承接选题和通知,后续把主流程迁入中控台,飞书只保留备用选题与任务完成通知。

v2.2 2026-03

Mode B 论文速览支线

在 Mode A 日报基础上新增 Mode B,专门处理 OA 论文深度解读。引入 8 条硬规则约束输出结构,严禁输出原文之外的任何内容。

v2.3 2026-04

display_no 取代 rank

原 rank 字段允许跳跃,大模型多轮对话中数字漂移导致选题确认错位。改为 1-N 连续编号 + display-map.json 反查机制,稳定性显著提升。

v2.4 2026-04 · 当前生产版

RULES.md 抽出 · 8 条硬规则刻入文件

将写作约束从 prompt 中抽出,固化为独立 MODE_A_RULES.md / MODE_B_RULES.md 文件。writer 必先加载,后处理 banned_word check。该版本运行至今,各项指标稳定。

10 LESSONS IN FAILURE

五个有真实代价的踩坑

每个坑都对应过实际的生产事故,以下记录问题表现、根因定位与最终修复方案。

VPN 自动连上,IP 出白名单
01

VPN vs IP 白名单 · 排查 6 小时才意识到要走专线

部署初期所有 DeepSeek API 调用全部 401,排查覆盖了 token、签名、payload 格式,均无异常。最终发现服务器挂着 VPN,出口 IP 不在 DeepSeek 白名单内。修复:服务器通过专线接入,不使用 VPN。

网络 / 部署
writer 输出在【06】卡片中段截断
02

DeepSeek 8K 单次输出截断 · Mode B 长论文经常断头

Mode B 论文速读 5 个 PART 一次性输出,经常在 PART 4 中段被截。改为分段生成 + 显式拼接,每个 PART 独立 chat call,context 中传上一段输出做衔接。

模型 / 输出
系统识别 arxiv/2504.000 为伪 URL
03

大模型对编造 URL 零抵抗 · 必须系统层反查

早期版本中,模型偶尔会输出"看起来很合理"但实际不存在的 URL(如某期刊文章页)。仅靠 prompt"严禁编造"无效。修复:writer 输出后强制对每条 URL 做 HEAD 请求验证,失败项打回重写。

幻觉 / 验证
备用飞书通知太长被拒 + 分段发送
04

备用飞书通知长度限制 · 一次发太长直接报错

候选摘要和完成通知一次性推送过长时,会触发飞书 API 单条消息长度上限。修复:小德按段拆发,每段不超过 10 条,卡片之间加视觉分隔,并确保中控台主流程不受影响。

平台 / API
OpenClaw 4.24 在 Windows 下 channel exited Received protocol c: ESM 错误,auto-restart 7/10 循环重试
飞书插件 feishu_chat / feishu_doc / send_as_bot 多通道全部 400 + 消息回复 fallback
05

OpenClaw 框架不稳定 + 通知通道兜底

OpenClaw 2026.4.24 在 Windows 下报 Received protocol 'c:' ESM 模块加载错误 (左图,auto-restart 反复 7/10);同期飞书插件 API 多通道(feishu_chat / feishu_doc / send_as_bot)频繁返回 400 (右图,疑似 token 失效)。临时方案:回退 OpenClaw 4.2 + 改用 deepseek-chat 路由绕过 V4-Pro reasoning_content 不兼容;后续不再让飞书承载主流程,改为中控台完成 99% 操作,飞书只保留备用选题和完成通知。

框架 / 通知兜底
11 REFLECTIONS

五条个人反思

以下是项目过程中得到的方法论判断,适用于 LLM 应用工程的真实落地场景。

01

业务约束的工程化,价值大于 Prompt 工程

让一个真实业务跑稳的关键,不是把 prompt 写得多精巧,而是把业务规则变成可验证的文件——skill.md、scoring 函数、后处理 check。Prompt 是表达,约束是工程。

02

小步迭代优于大版本规划

v1.0 单 agent 先跑通,再逐步拆分;先解决 80% 高频问题,再优化长尾。这种节奏比一次性设计完整架构推进得更快,也更容易在真实运行中发现关键瓶颈。

03

幻觉防护必须在系统层,不能依赖 prompt

LLM 对"听起来合理但实际不存在的内容"零抵抗力,尤其是 URL、数据、引用。仅靠"严禁编造"指令无效。必须在系统层做强制验证——HEAD 请求、域名白名单、对照原文反查——否则幻觉一定会进入生产。

04

需要业务判断的位置,必须留 placeholder

AI 生成内容越像越要小心。涉及商业判断、对外口径、决策权属的位置,系统不应替业务方决策,而应输出 [PENDING_OWNER_DECISION] 占位让真人填。这条边界对建立信任至关重要。

05

平台兼容性是真实成本,不是工程附属

微信 HTML 限制、模型 API 截断、IP 白名单、中控台状态同步、飞书通知长度——这些"工程基础设施"问题占据项目约 30% 时间。规划时必须把它们计入主路径,而不是当作可选的优化项。