为什么简单 Python 自动化经常比 AI Agent 更靠谱？

一位长期为企业做自动化开发的程序员分享了一个让他感到困惑的现象：客户经常要求“AI Agent”，但真正需要的是用代码自动完成重复性任务。在他看来，简单 Python 自动化往往比 AI Agent 靠谱得多——因为它们确定、稳定、不需要人盯着，也不会胡编乱造。这个观点引出了不少同行的共鸣，也带来了一些非常实用的补充。

客户说要 AI Agent，其实只是想要自动化

这位开发者表示，他给企业做了大量自动化，也把自己每周 20~30 小时的工作自动化了，但一直没真正做过一个完整的 AI Agent。他说：“大多数说想要 AI Agent 的人，并不是真的想要 AI Agent，只是想要一段代码自动执行重复任务。十有八九，简单 Python 代码就能搞定。”

评论区一位同行讲得很实在：“现在公司动不动就说‘我搭了个 Claude 项目去做某件事，每条记录要花 3 美元’。可那个流程里的每个步骤都是标准的、可批处理的操作，我每 5 分钟跑一次都免费，为什么要付钱给 Claude？”

还有资深咨询师点破其中门道：理想情况下，客户只谈问题和期望结果，咨询师来设计方案。但现实里，客户经常连解决方案也一起指定了——而解决方案往往不在他们的专业范围内。这时一个常见技巧是：顺着客户说“好，我按你的要求加了 AI”，然后实际用一个本地运行的、确定性的逻辑（比如 switch-case）来处理异常输入。这样既满足了客户的表面需求，又不会引入不可控的模型输出。

确定性 vs 非确定性：自动化为什么更可靠

核心问题在于：LLM 和 AI Agent 本质是非确定性的。这位开发者说：“它们太不可靠了，迟早会幻觉出糟糕的输出，所以必须有人盯着。”而普通 Python 自动化是“纯确定性代码，保证每次运行结果都一样”。

评论里也有人点出一个关键区别：真正的“语言模型”特指自回归文本生成模型，而不是嵌入模型、分类模型等。所以很多人讨论的“大模型”，其实只是把“大”理解成参数规模。一位搞笑评论给出一个“0 参数 LLM”的示例：

def dadgpt(prompt: str) -> str:
    return "Ask your mother"

这当然是玩笑，但提醒了一个事实：在自动化流程里，很多所谓的“智能判断”其实可以用简单的规则、条件分支或布尔逻辑完成，根本不需要上模型。

真正适合 LLM 的位置：写代码，而不是当 Agent

这位开发者并不排斥 AI，他说：“我非常喜欢用 AI 帮我写 Python 代码，这实际上非常有帮助，但这和用 AI Agent 是完全不同的两件事。”在他的自动化里，只有某些需要“判断”的极小步骤会调用一次 LLM，其他一切用纯 Python。

一位有 20 多年经验、日常重度使用 AI 的同行给出了更系统的做法：先用 AI 理清整个工作流，然后把流程固化成稳定、可重复的函数/模块/脚本。如果某些能力是 AI 技能，也最好让这些技能由脚本支撑，并给脚本增加参数。目标是“结果的稳定性”——用 AI 的灵活性加上代码的稳定性来取胜。

他举了一个很具体的案例：用代理在 WhatsApp 上协助妻子处理活动策划的临时需求。需求包括检查 Excel 文件里哪些服务器已经分配给活动、根据活动类型和宾客数量计算服务人员并考虑他们的经验和性格搭配、估算车辆数量、生成 PDF 等等。这种复杂场景用 LLM 处理很容易，但一致性会差。所以他把关键环节拆成脚本：

车辆数量计算：给定物品列表和尺寸，估算所需车辆数，准确且固定。
生成 PDF：用模板填充数据，脚本接收车辆类型和运输物类型两个参数，保存文件并返回文件存储链接，AI 根本不需要读文档。
读取 Excel：一个脚本返回日期和人数的数组，另一个返回具体人选以及他们的优势和协作关系（有些人合作得好，有些不好）。

这样妻子在忙碌时只需发一条语音消息，几秒钟内就能得到“可以/不可以/约束条件”的答复，而不用停下来打开电脑。他也强调了硬边界的重要性：“AI 不会正确权衡这些限制，硬性条件必须由代码保证。”

客户坚持要“AI”？给自动化加一层 LLM 包装

有时候客户并不是真的需要 AI，而是需要向外界说“我们用了 AI”。一位评论者说：“公司想对客户说自己在用 AI，即便实际效果不如自动化，也没关系。”这种“AI 热”让不少人为了营销而硬上模型。

对此，有人给出了一个很实用的建议：“如果你必须给自动化流程加上 LLM，那就让每次自动化触发时，发送一条由 LLM 生成的消息。恭喜你，这就是一个 Agent 了。”另一个评论则更稳妥：“在自动化任务的结果里加一个 LLM 生成的摘要，哪怕没人看。这样既满足了客户对 AI 的期待，又没有影响核心流程的确定性，而且也不算欺诈——LLM 确实参与了某个看似合理的环节。”

还有人从项目经理角度建议换个说法：“不要用 LLM 做自动化，而是让 LLM 来写自动化。”理由包括：一次固定成本、之后每查询零成本；减少对外部提供商的依赖；LLM 会写测试保证行为稳定；发现问题可以自动修脚本并加测试。这些话术听起来高大上，实际也没错，但核心仍然是——让 AI 服务于代码，而不是反过来。

处理建议

如果你也被问到“能不能做一个 AI Agent”，先别急着上模型。先和对方明确：到底是要一个能理解复杂上下文、自由对话的智能体，还是只是想省掉每天重复的手工操作？如果是后者，写一个 Python 脚本通常更便宜、更稳定、更容易维护。可以把 LLM 用在“写脚本”或“解释结果”这种辅助环节，但真正的决策逻辑尽量用确定性代码。这样既能满足 KPI 里的 AI 指标，也不会在客户面前翻车。