在研究工作流应该怎么落地的过程中，我突然有了一些新的想法，急于立马跟你探讨一下。

原来，我看到n8n/langgraph/dify这些严格的dag工具让我不悦，是因为它们过于强调工作流的严格图形走向，其实丧失了代码的灵活性和可追溯性，对于复杂流程而言，代码反而是经过验证的最清晰的方式。所以我想用类似于prefect/dbos这样的基于pydantic-ai的工作流引擎，它们更对代码友好，而且更对coding agent友好。

于是，我发现了一个好处，对于一个workflow而言，ai并不是必须的，如果每一步都是非常确定的，其实它就仅仅是一个代码的走向而已，反而是更稳定的。而即使是需要ai，那其实llm的context是约束在了某一个step当中，它的输入（包括参数、注入的参考资料、dag来源）都是固定的，输出也大多是结构化的，其实这种情况下context简洁清晰，不容易像是在cc/codex的工作流那样夹带不可预知的context，走向不可预知的流程，并且还能节省更多的token消耗。所以，我认为这种方式对于固定工作流是非常好的

但是，我也想到，在cc/codex/openclaw/hermes中让ai执行任务，即使消耗token，即使存在一定的不可确定性，但大家仍然愿意这么做，除了可以偷懒以外，有些工作流也很难提前非常明确。所以我想在这两者之间，也许存在一些中间，或者过滤状态，即对于固定流程要通过引擎来严格约束，对于当中不确定的地方可以先让llm来决策，这样可以达到一个平衡状态。如果是这样，dify/n8n等要求先画一个graph的方式就更差劲了。因此，未来我们应该有一个好的workflow engine，然后要求我们把可以明确的地方都明确好，然后把llm限定在应该灵活的区域，以此来获得确定性和灵活性的最佳平衡