为什么松散 agent 不好用：workflow-first agent 的设计原则

松散 agent 的核心问题，是它没有稳定继承人的工作质量。

很多 agent demo 看起来很惊艳：它会思考、会调用工具、会搜索、会写代码、会给出总结。但我越来越怀疑这种“自由发挥式 agent”能否直接成为生产力。

生产力不是一次完成任务，而是重复、可控、可验证地完成任务。一个 agent 如果没有明确的工作流，它每次都要重新理解目标、重新选择路径、重新组织工具、重新判断完成标准。这个过程很像一个聪明但没有团队规范的新同事。

所以我对 agent 的判断变得更保守：agent 可以自主，但不能无结构；可以动态，但不能无边界；可以调用工具，但必须被 workflow 和 harness 包住。

demo 追求惊喜，生产系统追求可重复。

松散 agent 在 demo 里容易赢，因为 demo 只需要让人看到模型能做很多事。生产系统不同，它要面对上下文污染、工具失败、权限边界、用户中断、状态丢失、成本失控和质量回归。

一个 10 步任务，如果每步成功率是 99%，端到端也会明显下降。更现实的是，agent 的每一步还可能改变环境，前一步的小错会放大后面的判断。

workflow-first 的价值就在这里：它把任务拆成稳定阶段，把关键节点变成验证门，把失败变成可恢复路径，而不是把所有复杂性塞给模型。

workflow-first agent 的 6 条设计原则。

第一，先定义输入输出，再讨论智能。一个任务如果连完成标准都不清楚，agent 的自主性只会放大歧义。

第二，先固化高频路径，再开放低频分支。不要让 agent 每次都临场发明流程。

第三，工具暴露要最小化。当前阶段不需要的工具，不应该出现在上下文里。

第四，验证必须前置设计。测试、类型检查、浏览器截图、人工审批、审计记录都应该是 workflow 的一部分。

第五，状态要在外部可见。重要进度不能只存在对话历史里。

第六，失败要被返回给 agent，而不是静默吞掉。错误信息本身就是下一轮推理的输入。

好 agent 不是替代 workflow，而是执行 workflow。

我心里比较理想的 agent，不是一个永远自由探索的主体，而是一个理解 workflow 的执行者。它知道当前阶段的目标，知道可用工具，知道哪些地方必须验证，也知道什么时候应该停下来请求人类介入。

这类 agent 的智能体现在三个地方：选择合适 skill、处理 workflow 中的异常、在证据不足时主动补证据。它不是每次都从零开始，而是在既有工作系统里做动态决策。

如果把 workflow 看作轨道，agent 不是被轨道束缚，而是终于有了可以高速运行的基础设施。

失败处理是生产 agent 的分水岭。

玩具 agent 常常把失败包装成“我完成了”。生产 agent 必须把失败显性化：工具没执行、权限不够、文件没找到、测试失败、上下文不够、用户目标冲突，这些都应该成为状态，而不是被一段自信的文字覆盖。

workflow-first 的 agent 应该有明确的失败协议：重试几次、换哪条路径、什么时候降级、什么时候升级给人、如何保留现场。

这也是 IntentDNA 后续要关心的地方。治理语言不只是表达“应该做什么”，还要表达“做不到时如何诚实退出”。

IntentDNA 应该治理 workflow-first agent，而不是鼓励松散 agent。

如果 IntentDNA 的目标是帮助公司治理 agent 行为，那么它不应该只给 agent 一些口号式原则。它应该能描述 workflow 阶段、角色边界、工具权限、验证门、handoff 产物和证据要求。

这意味着 IntentDNA 的价值不在“让 agent 更自由”，而在“让 agent 的自由发生在可治理的结构里”。

未来最好的 agent 不是最会自由发挥的 agent，而是最会把成熟工作流执行到位、把异常暴露出来、把证据沉淀下来的 agent。

这些判断背后有清晰的行业信号。

我引用这些来源，是为了把个人判断放回更大的市场、资本和工程实践背景里。它们共同指向一个趋势：AI 的竞争点正在从“模型调用”转向“工作系统设计”。