大家好！随着 LangGraph、CrewAI、PydanticAI 等开源框架的爆火，技术圈似乎陷入了一种“无 Agent 不开发”的狂热。许多开发者在接到一个自动化需求时，第一反应就是：“我是不是该引入一个 Agent 框架来做？”
为了解答这种“框架焦虑”，今天我们不妨“解剖”一下我们自己的开源项目——Blogger Agent，来聊聊：传统的控制脚本与现代的 Agent 框架究竟有何区别？到底什么时候才真的需要“杀鸡用牛刀”？
案例剖析：Blogger Agent 到底是不是 Agent？
Blogger Agent 的核心愿景是“自动将 Markdown 文章发布到各大平台（微信公众号、掘金、CSDN等）”。
如果我们看它的底层代码实现（例如 WechatPublisher 或 csdn.py），我们会发现：它并没有在内部实例化任何大语言模型（LLM）去“思考”下一步该怎么点。相反，它是由一套极其严密的 Python 状态机和 AppleScript 脚本构成的： 1. 检查浏览器标签页是否存在。 2. 注入标题和正文。 3. 等待 UI 渲染，通过脚本精确点击“下一步”。 4. 处理分类和标签弹窗。
结论很明确：在核心的“发布执行”环节，我们完全没有使用 Agent 框架，而是使用了纯粹的脚本流（Script Flow）。
为什么？因为这里的任务是确定性（Deterministic）的。微信的发布按钮永远在那个位置，标签框的交互逻辑是固定的。如果引入 LLM 让它自己去“看”页面并决定怎么点，不仅速度极慢、成本高昂，而且极其容易因为“幻觉”导致点错按钮。对于确定性的 GUI 自动化，传统的脚本控制依然是王道。
脚本控制 vs Agent 框架：核心分水岭
在上面的插图中，我们可以很直观地看到两者的区别：
- 脚本控制（上半图的流水线）
： - 特征
：强规则导向，基于 if/else 和状态机。 - 优势
：100% 的可靠性，极高的执行效率，零“幻觉”。 适用场景：数据清洗、API 搬运、固定的 UI 自动化测试、按部就班的发布流。
Agent 框架（下半图的无人机群）：
- 特征
：目标导向，基于大模型的概率计算（Probabilistic）。 - 优势
：极强的柔性适应力，能够处理未知的异常，支持多步骤的自我规划。 - 适用场景
：开放性问题、需要动态调用工具的场景。
那么，哪些场景才真正需要 Agent 框架？
如果你在犹豫要不要引入 LangGraph 或 CrewAI，请对照以下三个条件，如果满足其一，那么 Agent 框架的价值才会真正显现：
1. 目标是开放式的（Open-Ended Goals）
如果你的任务是“每天早上搜集 AI 领域的新闻，筛选出最有价值的 3 条，并总结成一篇文章”，这个过程没有固定的代码路径。Agent 需要自己决定用什么关键词去搜索，搜不到该怎么换词，这就是 Agent 框架的用武之地。
2. 需要动态的工具链与自我纠错（Dynamic Tooling & Self-Correction）
当执行过程可能随时失败，且修复路径不可预测时。例如一个专门修复代码 Bug 的 Agent（如 OpenDevin），它可能需要先跑测试代码，看报错信息，然后再决定是修改代码还是去翻看官方文档。这种动态流转只有 Agent 框架（如 LangGraph 的循环节点）才能优雅处理。
3. 多角色辩论与协作（Multi-Role Collaboration）
像 CrewAI 擅长的那样，你需要一个“内容创作者”先写初稿，然后传递给“技术审核员”挑错，最后交给“主编”润色。这种需要不同 System Prompt 互相制衡的复杂工作流，硬写代码会非常痛苦，使用 Agent 框架则是水到渠成。
总结：让脚本归脚本，让 Agent 归 Agent
回到 Blogger Agent 项目本身，它揭示了现代 AI 架构中一个非常重要的设计模式——Harness（脚手架/技能）模式。
Blogger Agent 本身是一个纯脚本构建的“脚手架”，它非常可靠且死板。但我们通过 MCP（Model Context Protocol）将它暴露出去后，像 Claude Code 这样真正的顶级 Agent 就可以调用它。
高层的 LLM 负责“智能决策”（写什么文章、配什么图），而底层的 Blogger 脚本负责“确定性执行”（如何点击页面把文章发出去）。
这就好比人类：大脑负责规划（Agent框架），而肌肉记忆（脚本控制）负责执行具体的动作。不要陷入框架焦虑，杀鸡千万别用牛刀，选择最契合业务确定性程度的工具，才是架构设计的最高境界！