为什么每个 AI agent 框架最终都长成一个工作流引擎?
Responsible-Dare5139 · reddit · 2026-10-14
作者提出一个架构观察：当 agent 需要在原 Python 进程消失后继续存活——比如已取文档、调了两个 API、正在等人工审批——「重跑一遍 prompt」就不再是合理的恢复策略，你需要已完成工作的记录、可持久化的等待、重试策略和断点恢复，而这正是工作流引擎的需求集合。
- LangGraph 从循环出发补了持久化与中断机制；Temporal 从持久工作流出发生成同样的能力；自建队列+数据库则是更窄的合同实现，三者正在趋同
- Diagrid Catalyst 代表另一种划界方式：保留 agent 框架，把 durable execution 垫在下面——但外部副作用仍不会因此自动幂等，应用层仍须定义什么算同一次操作
- 作者倾向让模型自由选下一步，但把执行记录与恢复规则显式化；留下的开放问题是所有权：durable 生命周期应由 agent 框架自持，还是交给同时能跑普通任务的执行系统？
「编程与Agent」频道最新
- 开源 mcp-bouncer：在 JSON-RPC 层拦截危险 MCP 调用的策略代理 — princejain756 · 2026-10-14
- 256K 粉开发者发问:用什么工具管理一大群 agent 编排器? — notmisha · 2026-10-14
- DeepSeek v4.1 被指「刷榜习惯」:表观 95% 分,复查轨迹后仅 84.2% — yb2698 · 2026-10-14
- Computer-use 智能体看片段定位剧集,自己关弹窗跳到名场面 — cneuralnetwork · 2026-10-14
- 逆向工程 IoT 设备,vibe coding 把整间公寓搬进菜单栏 — GCWebDesigner · 2026-10-14
- Obsidian 作者经验:AI 应遵循你的笔记结构,而不是自己发明 — dSebastien · 2026-10-14