AI 笔记三：详解工作流与智能体的本质差异
工作流究竟是什么？它与 AI 智能体有何区别？又该如何选择使用？01.所谓 AI 工作流，是指将一系列任务按既定顺序排列，由系统自动逐 Execution 完成。每一步的具体操作及后续流向，均在设计之初就已锁定。不妨将其视为一条自动化生产线。举例而言，若要生成日报：先提取数据，接着进行分析，随后绘制图表，最后发送邮件。每个环节都是预设好的，今日如此，明日亦然。无论数据如何波动，流程步骤始终不变。工作流最显著的特征在于确定性。输入相同，输出必然一致。它不会自行判断“今日数据异常，是否需调整处理策略”，也不会
AI Native 产品设计：选错路径将酿成致命错误
近期我正在开发一款项目管理 Agent，目标是打通整个研发链路：从需求创建起步，历经产品方案、技术方案，再到借助 AI Coding 完成前后端代码编写，最终通过测试、验证直至上线交付。起初我的理解是，AI Native 即由一个 Agent 全盘掌控研发链路。人类仅需设定目标，Agent 则包揽规划、工具调用、任务推进与问题解决。然而深入实践后，我发现实际情况远比预想的复杂。在真实场景中，至少存在三种截然不同的 Agent 工程架构。即整个系统仅有一个核心 Agent，例如项目经理 Agent。它承担需
控制AI的关键不是Prompt，而是这套工程架构
很多人以为AI开发就是：中间缺了一整层。现实中的软件开发是这样的：AI 为什么容易跑偏？不是 AI 不会写代码。是你把中间所有工程管理过程全部省略了。那怎么让 AI 也能按这套流程走？答案不是写更好的 Prompt，而是写三样东西：Spec、Agent、Skills。很多人把这三样东西搞混了。有的把 Spec 写进了 Prompt，有的把 Skills 当成了 Spec，有的把 Agent 和 Skills 混为一谈。其实它们的关系很简单，就一层：Spec 定义规则。Agent 按规则工作。Skills
LLM智能客服架构重构与优化
一次从"让 LLM 自由发挥"到"用状态机精确控制"的架构重构实践最近我对自研的 AI 智能客服系统做了一次比较彻底的架构重构——V4 版本。这次重构的核心变化是：从向量记忆驱动转向了状态机驱动。V4架构图：简单说就是：以前每个环节都丢给 LLM 去"自由发挥"，现在用结构化状态 + 显式规则来控制流程。效果很直接——Token 消耗大幅降低、流程完全可控、可观测性也好了很多。这篇文章分享一下这次重构的思路、做法和一些具体的代码实现。先快速回顾一下这个系统的