技能介绍

动手做 AI 应用的团队迟早会撞上同一个两难：把业务流程硬编码成一条流水线，逻辑可控但每加一个分支就得改代码；还是把控制权交给 LLM，灵活但行为不再确定，上线后只能靠祈祷。更麻烦的是，这个决策通常没有明确的判断标准——「我们的客服机器人到底该算工作流还是智能体？再加一个工具调用算不算智能体化？」

这个技能提供的是一套判断与设计的语言，而不是一套可以直接 import 的运行时。

技能内容整理自 LangChain 创始人 Harrison Chase 与 Dust CEO Stanislas Polu 的一次对谈，落地为六个可操作的框架：

智能体化光谱：用 LLM 决定控制流的程度 这一个连续变量（0% 到 90%+）替代「是不是智能体」的二元判断，用来判断一个系统该引入多少自主性。
工作流 vs 智能体：从控制流、确定性、构建难度、安全性四个维度对比两种范式。核心洞察是二者常常是同一件事的不同描述方式，选工作流通常是为了安全，选智能体是为了灵活性和长期潜力。
环境式智能体架构：智能体不该只活在聊天界面里，而是监听 Slack、邮件、代码提交等事件流，并行处理、异步推进，危险动作走 human-in-the-loop 批准。
AI 迷雾法则：底层模型能力每 3-6 个月质变一次，六个月路线图在 AI 领域等于没有路线图。应对方式是愿景驱动、2-4 周的快速实验周期，并为「超级智能快速到来」和「平台期持续多年」两种场景同时下注。
防御性构建：当巨头可能复制你的智能体产品时，护城河来自执行速度、深度押注少数方向、以及更早的产品状态。
多智能体系统模式：路由、对抗、反思三种架构模式，并讨论了专门化子智能体与收敛到单一智能体之间的分歧。

这是框架与设计决策参考，不包含可运行代码、API 封装或模型调用层。
六个框架来自一次播客对谈，带有强烈的「创始人视角」：偏战略与产品判断，对工程细节（并发控制、状态持久化、成本治理、评测体系）几乎不涉及。
工作流 vs 智能体的取舍建议是原则性的。真实项目里更常见的做法是混合——主干用工作流保证确定性，关键节点交给 LLM 决策，本技能没有提供这种混合架构的具体切分方法。
「环境式智能体」一节描述的是演进方向而非成熟实践，落地前需要自行补齐事件基础设施与审批链路。