让 LLM 自己规划出逼近人类设计的任务序列——并保证可执行。
当前已验证:人类设计工作流 → 编译为 Agent → 弱模型稳定执行。
终极目标:LLM 自己完成"设计工作流"这一步。
读完之后你能回答三件事:
-
Unigen 解决什么问题——为什么主流 Agent 在长链条任务上不可靠,以及一条可行替代路。
-
Unigen 带来了什么——它如何把"任意人类智力工作流"转化为 AI Agent。
-
初步原理——一句话:逻辑向 AI,核心机制是 Validator 与本体空间。
上手步骤、代码细节、项目状态,见 Wiki 首页 与 快速开始。
| 形态 | 谁设计调用序列 | 例子 | 优点 | 缺点 |
|---|---|---|---|---|
| 通用自主 Agent | LLM 自己规划 | OpenHands、AutoGPT、Manus | 灵活，无领域预编排 | 长链条漂移、捏造 |
| 垂直专业 Agent | 人类工程师预设计 | Devin、Cursor、Claude Code、Bolt.new | 领域内质量稳定 | 每领域重做工程，扩展性差 |
| LLM 作为产品组件 | 工程师固化到产品中 | Grammarly、NotebookLM、DeepL Write | 最稳定，最易落地 | LLM 能力被裁到单点，撑不起复杂任务 |
真正的分界不在模型,在"谁设计调用序列"——这一点决定了质量、灵活性、工程成本的全部 trade-off。
学术与工程细节、对应的 CoT / ReAct / ToT / Reflexion / Self-Refine 等论文索引见 Wiki 首页第三节"论证浓缩"。
Unigen 的整套设计,起点是一个笨拙的问题:人类是怎么解决复杂问题的? 我们研究了这件事,把发现借鉴到 Agent 设计上——下面按这个研究过程的顺序,一步步展开。
面对一个复杂任务,人类的第一反应通常是先拆:把大任务拆成小任务、小任务拆成更小的步骤,再按依赖关系依次做。
这不是新发现。今天的 AI 世界里"任务拆分"已经无处不在:
-
Plan-and-Execute 提示词模式(先规划再执行)
-
Codex / Claude Code / Cursor 面对一个编程需求,先给出任务清单再逐条实现
-
ReAct 也是拆分的一种——每一步都是一次微拆分
-
AutoGPT / OpenHands 的核心循环就是"拆分—执行—再拆分"
Unigen 里对应的入口是 /plan 命令:输入一个需求,输出一个多层任务图。
不管用什么形式,任务拆分最终都产出一个执行序列——按依赖关系组织起来的步骤集合,每一步做什么、需要什么输入、产出什么。
问题随之而来:LLM 拆出来的这个序列,真的能跑吗?
要判断一个执行序列能否执行,人类通常这么想:
"这是不是一张 DAG?如果是,那 DAG 要满足这些条件才跑得通:无环、依赖闭合、交付完整……"
拆开看,这里发生了两步:
-
把具体的执行序列往上归类——归到"DAG"这个概念上。有些人把这一步叫"抽象",在逻辑学里它有个更精确的名字:升阶。
-
应用归属概念上的规则——DAG 概念自带一组规则(无环、依赖闭合……)。因为对象已被归入 DAG,这些规则就适用。
这两步合起来给出一个明确的判据:序列是否可执行、错在哪一步。
我们把"升阶 + 应用规则"这套机制封装成一段可运行代码,叫它 Validator(验证器)——这是我们自己给它取的名字,不是学术术语。
/plan 的工作方式就是这个模式的最小实例:
LLM 输出执行序列
→ 升阶为 DAG (对象 → 概念)
→ 应用 DAG 可执行性规则 (无环、依赖闭合、交付完整、边界一致)
→ 通过 / 具体错误反馈
→ 有错就让 LLM 修,直到通过
一致的实测:只要 LLM 最终给出结果,一定可执行——弱模型也是如此。对照观察:即便 Claude 4.x 这类顶级模型,在没有 Validator 反馈的情况下,对复杂规划仍可能输出无法执行的答案——它自己没有工具能验证。
Validator 建好之后回望,会发现"升阶 + 应用规则"正是两千多年前亚里士多德的三段论:
-
大前提:"DAG 必须满足这些可执行性规则"(规则,附着于概念"DAG")
-
小前提:"这个执行序列是一张 DAG"(升阶——把具体对象归入概念)
-
结论:"这个序列是否可执行,由这些规则判定"
这不是巧合。逻辑学从一开始就是研究人类思维的学问——两千年来,人类把"人是怎么做判断的"提炼成一套形式化机制,又把这套机制留给我们借用。Validator 只是把三段论工程化。
Unigen 的整体路线就叫逻辑向 AI——不是让 LLM 学逻辑,而是让 AI 系统在逻辑骨架上运行,LLM 只在骨架内做局部填充。详见 [[逻辑向 AI|Logic-Oriented-AI]]。
回到 /plan。"可执行"只是众多需求之一。真实工作流有更多需求:
-
内容一致性(人物设定不能前后矛盾)
-
事实依据(不能凭空捏数据)
-
时效性、成本约束、领域规范……
这些需求带来两种复杂性:
广度:一个节点可能需要多个 Validator——DAG 检查一次、事实核查一次、成本核算一次。广度让问题变复杂,但复杂性是可加的、并行的、有限的——写更多 Validator 即可,不会失控。
深度:每个 Validator 里"该升阶到哪个概念、应用哪些规则"这件事,本身就是一个判断。判断一个判断,又需要一个判断……
深度才是真正的难题。因为它是递归的,不是可加的。(广度不递归,广度只是让每一支上各自继续深度递归。)
有意思的是,"该升阶到哪个概念"这个问题,本身就是一个 Plan 问题——需要拆分、需要升阶、需要 Validator。也就是说:同一套方法可以递归复用。
但这不解决问题,只是把问题推给下一层——每一层"选哪个升阶方向"又会引出新一层的判断:
判断"序列是否可执行"
↓ 需要判断:该升阶到 DAG 概念吗?
↓ 需要判断:DAG 的哪些规则适用?
↓ 需要判断:这个规则子集覆盖了原始需求吗?
↓ ……
从算法角度看,这个套娃过程就是 Horn 消元 / SLD 归结——在一个规则库里搜索一条从"目标"到"已知"的证明路径。经典符号 AI 早就在做这件事。
问题也随之来了。
Horn 消元有一个前提:你得先有那个规则库——概念的层级结构、规则的适用条件、概念之间的关系。这套东西叫本体空间(ontology space)。
有本体空间,Horn 消元就是查图。没有本体空间,Horn 消元无从下手。
符号 AI 六十年折戟于此:
-
Cyc(1984 起,至今)——手工构建通用本体,数十年、数千人年,至今商业化有限。
-
KRL / OpenCyc / SUMO 等一系列尝试——都在"手工构建太贵" vs "自动构建质量太差"之间摇摆。
近年"让 AI 动态扩充本体空间"的思路又被重新拿起(自维护知识图谱、LLM-augmented ontology 等),但共同的困境仍在:本体空间需要保持一致性,否则规则之间互相矛盾,查图得不到确定结论。
要让一个不断增长的本体空间严格自洽,恐怕做不到。哥德尔不完备定理告诉我们:任何足够强的一致形式系统,都存在系统内既不能证明也不能证伪的命题——形式系统封闭不了自己。
现实中的本体空间只能"大部分一致 + 允许局部冲突 + 冲突时有兜底策略"。这仍然是开放问题。
绕不开的问题于是变成:
让一个 Agent 稳定运行,最少需要多大的本体空间?
Unigen 目前正在尝试若干方向探究这个"最小"到底该是什么样——不同任务类型是否共享一个基础本体、领域本体如何在基础本体上叠加、本体如何随任务运行逐步扩充、局部一致性如何维护……都是开放研究。
这就是通用方向卡壳的地方:最小本体空间尚未清晰,自动化就无从谈起。
研究上再难,现实里有一个绕不开的事实:每个正常人脑里已经有一个本体空间。
一个懂博弈论的人在 21 点上会直接给出正确答案——不是因为他现推,而是他脑里的博弈论知识就在那里。一个懂医学的人诊断疾病、一个懂电商的人写软文,都是同样的机制。
这意味着——只要把人类领域专家的本体空间显式注入系统,就能立刻绕开"最小本体空间尚未清晰"的理论难题,做出高质量的 Agent。
这就是当前已验证的方法,也是 Unigen 今天最直接可用的东西。
面对一个反复做过的人类智力工作流,做三件事:
-
将工作流拆解为节点——一段人类看得懂的《岗前培训手册》即可。
-
对每个节点,人工做一次"升阶"——判断这个节点属于哪个概念(如"DAG 子任务""事实校验""格式归一"),需要哪种规则。
-
为每个节点撰写 Validator——形式有三种:
- 代码校验(规则是确定性的,如 DAG 可执行性)
- LLM + RAG + Rerank(把开放判断转成查表:答案空间已知时,把 NP 推理降级为检索)
- LLM 评审(纯规则、纯感知类判定,如文风是否符合)
三件事做完,任意一个人类智力工作流就变成一个稳定的 Agent——即使跑它的模型比设计时预想的还弱,只要工作流拆得足够细,质量仍能稳定。
-
不依赖大模型——工作流决定质量上限,模型决定成本下限。
-
可复用——一份《岗前培训手册》→ 一个项目类型 → 无数用户使用。
-
可审计——每个节点的判断标准是显式的,出错可以精确定位到哪一步。
-
门槛是"领域知识"而非"工程能力"——只要你能把"怎么做这件事"写下来,就能做出一个 Agent。
我们用这套方法实测过大量 Agent,仅为验证路线可行性:从产品说明生成公众号软文、几十万字长篇小说、剧本到视频;还包括 LLM 单次对话很难做对的问题——例如 21 点的最优策略(LLM 直觉给出"模仿赌场"的答案,但数学最优策略在不同赌规下差别极大,需要精确查博弈论规则表才能答对)。
一致的结论:只要人类把工作流设计得足够细,弱模型也能稳定跑出高质量结果。
方法本身不需要 Unigen——你完全可以用纸笔、Python、LangChain 或任何工具实现。
Unigen 是为支持这个方法提供的便利工具集:
-
提供了 Validator 撰写与挂载的标准化框架——避免每个 Agent 从头搭一套校验管道。
-
内建了 DAG 可执行性 Validator(
/plan命令)——最基础也最常被需要,直接给到。 -
提供 工作流工坊项目类型——把《岗前培训手册》一键编译成新的项目类型供创作者使用。
-
提供 反思助手——便于领域专家快速迭代 Validator 与工作流节点。
-
提供了几个通用目标的测试代码与 demo(剧本 → 视频、产品 → 电商图)作为示范。
换句话说:方法是一回事,Unigen 是这套方法的加速器与样板间。
从第 3 节的方法描述里,自然分出两条路线,各有各的难处。
| 方向 | 做什么 | 优点 | 难处 |
|---|---|---|---|
| 路径 A：专用方向 | 选领域，召集专家，把工作流 + Validator 写好 | 今天就能出可商业化的高质量 Agent | 领域太多，每个领域都需要领域专家配合，扩展靠人力 |
| 路径 B：通用方向 | 让 LLM 自己学会“如何把任意工作流拆好 + Validator 写好” | 一次能力突破，所有领域受益 | 最小本体空间尚未清晰（见 2.10），工作量浩大，处于研究阶段 |
这就是 Unigen 内部"摇摆"的来源。作者长期在两条路之间犹豫:
-
埋头做路径 A,意味着放弃探索 LLM 自身能力边界的可能性。
-
埋头做路径 B,意味着大量无即时产出的研究投入。
当前选择:两条路同时推。路径 A 已有可交付的成果,路径 B 是终极目标。
普通用户——只想用现成 Agent 做点事
不用看上面这些。你需要的只是:打开软件 → 新建项目 → 选个类型 → 填输入 → 点运行。
→ [[快速开始|Getting-Started]] → [[运行你的第一个工作流|Using-Workflows]]
领域专家——想把你的工作流做成 Agent
你已经有"怎么做这件事"的经验,你想把它沉淀下来。
→ 第 3 节讲的方法 → [[工作流开发总览|Developer-Guide]] → [[公众号软文完整例子|wedoc]]
对"通用方向"感兴趣——想知道 LLM 能不能自己学会设计工作流
→ [[逻辑向 AI|Logic-Oriented-AI]] → [[自改进的边界|self-improvement-boundary]] → [[路线图|Roadmap]]
| 能力 | 状态 | 说明 |
|---|---|---|
| 产品说明 → 产品电商图 | 可用 | 推荐第一个体验，链条短 |
| 剧本 → 视频 | 可用 | 弱模型稳定，视频 API 贵，建议先停在提示词 |
| 工作流工坊 | 可用 | 把《岗前培训手册》编译成新项目类型 |
/plan 自动规划 |
可用 | 仅 DAG 可执行性验证，规划质量粗糙，但结果一定可执行 |
/prism 多视角推理 |
可用 | 详见 棱镜推理 |
📚 深入了解 → Wiki
新用户
领域专家 / 开发者
通用方向研究者
-
提 Issue 报告 bug 或提建议
-
最需要的贡献:
- 领域专家分享一份《岗前培训手册》——这是路径 A 最有价值的资产
- 用真实复杂任务跑一遍,反馈成功与失败案例——失败案例尤其宝贵,失败案例是路径 B 本体空间积累的原料
- Star ⭐ 让更多人看到