AI 越来越强以后，我们还需要给它设计工作流吗？

整理 Praxis 的设计时，我反复碰到一个问题：如果 Agent 本来就会理解需求、读代码、制定计划和调整策略，我额外设计的那套工作流，到底补了什么？把任务拆成多个角色，再安排分析、设计、实现、审查，看起来很完整。但完整的流程图，并不能回答这些步骤有没有改善实际选择。

这篇记录的是我目前的设计判断。Praxis 已有原则、Skill 正文和有限验证，但还没有真实产品 Dogfood 的效果证据。我不能拿这段设计过程证明“去掉工作流以后，开发效率提高了”。

复杂流程为什么容易让人安心

给 Agent 设计流程，很容易从一种合理担忧开始：它会不会漏需求，会不会过早写代码，会不会忘记验证？每发现一种可能的错误，就加一个角色、一份文档或一道检查。这样做有可见的产物，也像是在把工程经验转化为系统能力。

问题是，可能犯错和已经反复犯错之间，隔着一段需要观察的距离。我现在会追问：这里缺的是项目事实、工具访问、判断提醒，还是必须被强制执行的边界？如果只是缺少已有约束，增加一轮“架构专家审查”可能还不如让 Agent 先看到正确的项目文档。

对我而言，思考的变化发生在这里：我开始把每一个额外步骤看成需要说明理由的成本。它会占上下文，会延迟行动，也可能让人不断确认已经说清楚的事情。流程的价值需要落在具体失败上。

能力变强以后，原来的扶手可能挡路

Praxis 把 Agent 会持续增强作为设计前提。这是前提，并非所有模型都已可靠的事实。如果 Agent 能依据新观察调整调查路径，而外部流程要求它必须先填完某种报告、经过某个角色，适应能力就可能被固定顺序压住。

比如事故恢复，可能应该先按已有授权止损，再继续辨别原因。若把“先彻底查明根因”写成普遍顺序，就会把某些正常开发场景里的习惯带进不合适的情境。反过来，恢复成功也不能让根因自动成立。需要保留的是这两个判断之间的区别，而非统一排列它们。

我还没有比较数据来证明强 Agent 总比编排系统好。我的担心更具体：当流程没有说明何时可以改变时，它可能把曾经有用的策略变成永久约束。模型升级后，这种约束还可能继续存在，因为维护者更容易添加步骤，很少删除步骤。

我现在更想设计它工作的环境

Design environments, not workflows. 这句话在 Praxis 里，指向目标、真实上下文、原则和边界。目标告诉 Agent 什么结果值得改变；上下文提供业务含义和已有决定；原则帮助权衡；边界说明哪些行动必须有现实授权或确定性保证。

例如“根据能区分解释的观察继续调查”，比“先执行某条诊断命令”更值得长期保留。前者帮助选择下一步，后者只有在特定环境里才有意义。同样，“只声明证据支持的范围”能跨任务使用，而一份统一的完成报告未必能让声明更准确。

环境也不只是一段提示词。缺少生产观察，就需要实际访问或明确保留未知；权限限制需要在真实执行边界生效；数据完整性可能需要数据库约束。不能因为强调 Agent 判断，就把这些保障交给一句“请小心”。

Praxis 当前做了什么选择

目前 Praxis 没有自己的 Runtime、Router 或固定开发生命周期。四个 Core 分别面向目标、结构承诺、原因判断和现实行动风险；八个 Expert 提供专业取舍视角。它们没有必调依赖或默认调用顺序，简单任务允许一个都不加载。

项目还保留了一个很具体的例外：为项目安装提供薄 CLI，处理文件身份、冲突、幂等和安全卸载。这些是需要可靠重复执行的机械操作。它没有因此接管 Agent 会话、规划或业务执行。这让我看到，“环境优先”仍然容得下边界清楚的确定性工具。

还没有回答的问题

没有固定流程后，Agent 能否在长任务里持续记住目标？按需指导是否会漏掉关键判断？哪些重复失败最终需要更强机制？这些仍是 UNKNOWN。当前的文档审阅和有限 smoke 不能替代真实产品中的观察。

这是我目前的判断，仍需要真实 Dogfood 验证。我希望观察的是：Agent 是否更早发现错误目标，是否选择了更有区分力的调查，是否少制造无用工作。若现实证明某个步骤确实不可缺少，就为那个问题补上保障；若没有增益，也应该允许删掉我自己设计的指导。