一位老开发者的AI Agent实践复盘：从手动管理到系统化思维

在AI工具层出不穷的今天，如何真正用好AI Agent而非迷失在「月抛式」的焦虑中？一位拥有十年开发经验的老兵，通过亲身实践走出了一条从手动管理到系统化思维的进化之路。他的经历告诉我们：真正的瓶颈不是AI不够聪明，而是人类注意力的局限。

80%的AI需求不需要AI

当作者同时打开5个AI终端时，真实的体验是这样的：codex在跑单元测试，gemini-cli在改接口，claude在生成文档，Cursor里同时开着两个Agent窗口。这种「人肉并发」模式的上限大约就是4-6个并发任务，再多就会导致上下文切换崩溃。人工并发存在三个硬伤：吞吐有限（一天只能管理4-6个窗口）、状态不稳定（上下文丢失、判断漂移）、难以规模化（成功经验难以复制）。

Vibe Coding的翻车与反思

作者在认真开始折腾AI时，第一件事不是调模型或搞RAG，而是写了一套Bash脚本来自动化日常工作流。结果发现——80%的「AI需求」根本不需要AI。自动拉取代码跑测试、定时检查服务健康状态、把JSON日志格式化成报表、文件变更触发构建……这些问题10行脚本就能搞定。这个认知演化成了一个决策层级：目标→代码→CLI→Prompt→Agent。每往上一层，不确定性增加一个量级，成本也增加一个量级。原则很简单：能在下层解决的，绝不上推。

24h打工人系统的诞生

在Vibe Coding翻车后，作者重新来过，这次先设计再动手。他构建了一个名为「24h打工人」的真正能24小时无人值守运行的Agent系统。核心架构极其简洁：文件+轮询。调度层做四件事：接收任务（用户反馈写入文件队列）、分发执行（轮询队列调用CLI执行）、状态管理（记录每一步输入输出持久化到文件）、失败切换（某个CLI配额用完自动换下一个）。系统最核心的概念是SDD（Spec-Driven Development），每个需求处理完会留下一组完整文档：spec.md把模糊需求变成明确目标，plan.md把目标变成技术方案，tasks.md把方案拆成可执行步骤。

从Task-Driven到Goal-Driven的跃迁

做完24h打工人后，作者意识到留痕只是起点，不是终点。很多Agent demo的问题不是不会跑，而是跑偏了完全不知道发生了什么。一个生产级Agent系统必须具备可观测性：当前目标是什么、正在执行哪一步、用了什么工具、为什么失败、是否触发重试/回退、成本消耗了多少。同时，评估必须是持续的——需求澄清是否稳定、任务拆解是否合理、Skill是否真的提高了成功率。 从Task-Driven到Goal-Driven的转变是本质区别：前者让人成为项目经理+执行监督，后者让人成为目标设定者/审核者。Goal-Driven的5个前提是：目标必须清晰、边界必须清晰、状态必须可见、过程必须留痕、权限必须可控。

如有侵权，请联系删除。