文章目录
数字人是企业 AI 应用的一道坎。人人都说要跨，但很少有人把"怎么搭"讲清楚。
这周我拆了 workbuddy 和 qwenwork 两个 C 端应用，又自己动手做了一套冲着企业端去的 skill graph。
工具、技能、智能体，三层。整个实践环节很多，一篇讲不完。这篇只挑我花时间最多的部分——skill graph。
一、为什么重心落在 skill graph 上
先说三层各自的状态，不然讲不清重心为什么落在这。
工具层，经过 MCP、function calling 几轮迭代，基本走通了。这层不是当下的瓶颈，谁在这卷都卷不出名堂。
技能层，最容易被低估。技能不是工具的包装，是流程契约——什么时候用、用完交什么、下游能不能接。workbuddy 中规中矩，qwenwork 让我看到一点不同的东西（具体哪不同，那是另一篇的事）。这层有设计空间，但不是最难的。
智能体层，最玄。核心问题不是模型多强，是"怎么让 AI 知道下一步该干嘛"。通用智能体磕磕绊绊，根因在没有持久化上下文，每一步都像失忆——跑到第三步忘了第一步产出什么，于是要么重复劳动，要么瞎猜。
而 skill graph，正好卡在技能和智能体的接缝上。它既定义技能之间怎么连，又给智能体提供"下一步走哪"的决策依据。三层里，这层最难、也最值钱。所以我把重心放这。
下面讲讲这套 skill graph 是怎么设计的。
二、graph 是地图：把技能关系定义死
一份 skill-graph.json，把所有技能节点和它们的关系定义死。核心字段长这样：
{
"id": "sdd-spec",
"phase": 3,
"required": ["sdd-evaluate"],
"reads": ["sdd-evaluate"],
"writes": ".chain/context/sdd-spec.json + 四文档",
"gate": ["公共 API、数据模型、架构或不可逆操作需要确认"],
"next_hint": {
"preferred": ["sdd-execute"],
"reason": "Spec 四文档齐备，进入实现按 tasks.md 逐项落地。"
}
}
几个字段的设计意图值得说。
required 是硬依赖——没跑完上游，这个技能不算 ready。空数组表示无依赖，恒满足。
reads 是软依赖——只用于画依赖线和排序，不卡 ready 判定。软硬分开，是为了避免"信息依赖"误伤"执行依赖"。上游产出我读一下就行，不该因此卡住你跑。
gate 是卡点——走到这必须停下让人类确认，防止不可逆操作一路冲下去。企业场景里，有些操作不能让 AI 自己拍板，必须停。
next_hint 是推荐——告诉下游"通常下一步走哪个"，但不是硬绑死，留给编排选择空间。
graph 的价值不是定义流程——流程谁都会画。graph 的价值是把依赖、卡点、产物、推荐放在一个机器可读的地方，让编排层有据可依，而不是靠 AI 临场判断。
三、chain 协议是记忆：让 graph 跨步骤不断片
graph 是地图，但光有地图，AI 跑长链路还是会失忆。这是通用智能体磕磕绊绊的根因——没有记忆载体。
我对这件事的解法是 chain 协议。每个技能跑完，必须把上下文写到消费项目的 .chain/context/<node-id>.json：
{
"node": "sdd-spec",
"spec_id": "SPEC-PROMO-003",
"summary": "订单模块 Spec 四文档齐备",
"artifacts": ["03.Document/01.specs/SPEC-PROMO-003/requirements.md", "..."],
"done": true
}
这份文件是链路的记忆载体。下游技能启动时，先读上游的 context 文件，沿用字段——不用重新理解会话，不用猜上游干了什么。哪怕会话断了、换了人、换了运行时（Claude Code 跑一半切到 Codex），链路状态都还在。
这里有一个真实教训。chain 协议里执行顺序是写死的：先写盘，再自检，再渲染报告，最后 handoff。为什么写盘必须在最前？因为我吃过亏——把写盘放最后，AI 的注意力被前面的渲染报告吸走，写盘经常被跳过。一个 frame.json 缺失，整条链路就断了。这不是理论推演，是试用时实打实栽过的坑。
写盘放最前，是这个协议里看起来最不起眼、但最关键的一条。它不优雅，甚至有点笨——但它保证了一件最重要的事：AI 的注意力再怎么飘，最该留下来的东西先落了地。
四、next-skill 算法：下一步不是猜的
还有一个细节值得单独说：下一步该走哪个技能，不是 AI 瞎猜的，是算法算出来的。
ready 判定不复杂：
- 哪些技能还没跑过？(
id ∉ done) - 它们的硬依赖都满足了吗？(
required.every(r => r ∈ done))
满足的，按几个维度排序：当前技能的 next_hint.preferred 优先 → 同阶段优先 → anchor 节点加权 → 被 更多下游 reads 引用的优先。算完输出前五个候选。
然后塞进 handoff 的三层模板：第一行说这个技能完成了、关键产物是什么；第二行列出算出来的候选；第三行给一句点拨，通常推荐 preferred 里的第一个。AI 不需要在全部技能里大海捞针，只需要在算好的候选里选，或者直接让用户选。
这就是智能体层的本质——不是让模型自己变聪明，而是给模型一个结构化的决策空间。graph 划定能走的路，chain 保留走过的路，算法算出最该走的路。模型只负责在给定的路里选，而不是从零规划。
五、harness：地图要有车才跑得动
回到我在草稿里写的那句判断：skill graph 的模式需要配合 harness 才能达到最好的效果。
这句话是我这段时间实践下来最深的体会。
graph 只是地图。你把技能、依赖、产物定义得再漂亮，它也只是一份 JSON。光有地图到不了目的地。harness 做三件事：
- 持久化上下文：chain 协议强制写盘，这是 AI 的记忆。没有这层，AI 跑长链路就是失忆患者。
- 强制执行顺序：写盘在前、handoff 在后，顺序不能颠倒——颠倒了就丢数据。
- 生成下一步候选：next-skill 算法实时算 ready 技能，塞进 handoff。AI 不用自己找路。
没有 harness，通用智能体跑 skill graph 就是磕磕绊绊——graph 在那儿，但它不知道怎么按 graph 走。有了 harness，graph 才从"一张设计图"变成"一条能跑的流水线"。
六、写在最后
搞 AI 这事，跟当年搞物理化学的科学家有点像。没人给你标准答案，你得不断探索、不断试、不断推翻自己上个月的判断。
这套 skill graph 是冲着企业端设计的。光是设计本身，就逼着人把技能的边界、链路的记忆、下一步的决策都想清楚。skill graph 管路由，chain 协议管记忆，next-skill 算法管决策，harness 把三者串起来跑。
这只是整个实践的一环。workbuddy 和 qwenwork 的拆解、企业场景的真正落地，都是后面要单独写的事。这篇只管 skill graph 这一摊。
数字人不是套个壳、接几个工具就能立起来的。工具好做，技能难整，智能体最玄。但 skill graph 这层搭对了，智能体层才有个站住的脚。
这条路还长，先走着。