把 Agent 工作流从“临场发挥”变成可复用产品

这次宣讲里，最值得拿出来讲的不是某个 demo 页面，而是一个很实际的问题：Agent 能跑通一次任务，不代表它下次还能按同样的方式跑。对个人探索来说，这没什么。对产品化、批量执行和团队交付来说，这就是坑。

方案的核心是把动态 Skill 编排提前固化成静态工作流模板。模板用 JSON 描述一张 DAG：输入从哪里来，节点按什么顺序跑，哪个节点执行命令，哪个节点要回到 Agent 补信息或做审核，执行状态如何保存。

它解决什么问题

Agent 最大的优点是灵活，最大的问题也是灵活。今天它理解了 Skill A 调用 Skill B 的方式，明天换一个上下文，可能自己写一段脚本绕过去。单次任务还能接受，几百个素材、几百条数据流水线、几十个项目机器人一起跑时，就会变慢、变贵，也变得难追溯。

静态工作流模板的价值，是把“跑通后的经验”保存下来。第一次可以靠 Agent 试错，第二次就不该再试错。流程被编译成图之后，确定性节点直接由 CLI 或脚本执行；需要语言判断时，再把控制权交回 Agent。这样既保留模型能力，又不让模型每一步都重新发明流程。

适合做成什么产品

最自然的产品形态，是面向 Agent 的 Workflow Orchestrator。它不一定要长得像传统 BI 或 OA 工作流，更像一个“Agent 流程打包器”。用户在本地把提示词和工具链跑顺，系统把这套链路变成可分发包，平台解析后直接运行。

素材生成平台很适合这类能力。运营调好一个图片、视频或音频玩法后，可以把流程上传，平台稳定复现，而不是每次都让模型重新理解。项目机器人也适合，比如固定拉取埋点、配置、收益和调用数据，再输出统一格式的日报或周报。

优点和短板

• 优点一：稳定。流程被图结构固定下来，输出更容易复现。AI 幻觉不会消失，但它能影响的范围变小。
• 优点二：可审计。每一步输入、输出、状态变更都可以落盘。出了问题，不用只看一段聊天记录。
• 优点三：能批量。重复任务不再让 Agent 每次重读完整 Skill，成本和耗时都会下降。
• 短板一：前期设计更重。一次性任务不值得这么做。流程越短、越临时，静态化越显得多余。
• 短板二：图模型要足够表达真实工作。只支持 command 节点还不够，后面需要接口节点、MCP 节点、人工审核节点、重试和回滚策略。
• 短板三：Agent 触发和状态恢复要做细。一旦中途等待人或模型补信息，状态机设计不好，恢复起来会很痛苦。

市面上有哪些类似东西

传统工作流领域有 Airflow、Prefect、Dagster、Temporal。它们擅长数据管道、后端任务和长事务编排，可靠性强，但默认不是为“让 Agent 读 Skill 并调用工具”设计的。

低代码自动化里有 n8n、Zapier、Make。它们适合连接 SaaS 和业务动作，上手快，但复杂的本地开发环境、代码仓库、模型工具链和状态审计通常不是强项。

Agent 编排里有 LangGraph、Dify、Coze、CrewAI 这类框架。它们离模型更近，适合做对话式、多 Agent 或带状态的 AI 应用。但如果目标是把一次 Codex/Hermes 里的本地工作经验打包成可复用 Skill，仍然需要一层更贴近开发者工作台的适配。

所以这类方案最有机会的位置，不是替代所有工作流系统，而是卡在 Agent、Skill、CLI 和产品平台之间。把人已经探索出来的流程沉淀下来，再交给平台稳定运行。