十年老技术开发的 AI Agent 探索之路¶

Ch04.019 十年老技术开发的 AI Agent 探索之路¶

📊 Level ⭐⭐ | 60.8KB | entities/ai-agent-exploration-legacy-developer.md

十年老技术开发的 AI Agent 探索之路¶

作者：zhiyuanfu

曾经前端被戏称为"娱乐圈"——工具、框架层出不穷，今年🔥 的明年就过时。现在 AI 把这个周期压缩到了以月计：这个月的新概念，下个月可能就是旧闻。这篇文章，就是一个在"AI 娱乐圈"摸爬滚打的老开发，试图从月抛式的焦虑中找到不会过期的东西，为大家抛砖引玉。

4-6 个终端的并发上限，怎么突破
80% 的 AI 需求，10 行 Bash 就够了
Vibe Coding 翻车全记录
24h 无人值守的代码开发 Agent 怎么造
从 Task-Driven 到 Goal-Driven 的认知跃迁

第一章：起点——人是瓶颈¶

此刻我的屏幕上开着 5 个终端。左上角，codex 正在跑一组单元测试，终端里绿色的 pass 和偶尔的红色 fail 交替滚动。右上角，gemini-cli 在按照我刚给的方案改一个接口的入参校验。左下角，claude 在根据最新的 API 变更生成文档。右边整块屏幕留给了 Cursor，里面同时开着两个 Agent 窗口——一个在重构组件，一个在补集成测试。看起来很酷？真实体验是这样的：codex 那个终端跑了五分钟没动静，我得翻上去看是卡住了还是在等确认；gemini 改完接口了，但我忘了它改的是哪个分支；claude 写的文档引用了一个旧接口名，因为我忘了告诉它刚才 gemini 改过了；Cursor 里的重构窗口弹了个确认框，我一直没注意到，白白等了十分钟。这种模式的上限大概就是 4-6 个并发。再多，人脑的 context switch 就开始崩溃。人工并发有三个硬伤： | 限制 | 具体表现 | 后果 | |---|---|---| | 吞吐有限 | 一天能管 4-6 个 Agent 窗口 | 任务量有硬上限 | | 状态不稳定 | 上下文丢失、判断漂移、质量波动 | 上午管 5 个，下午犯困管不了 3 个 | | 难以规模化 | 做成一次不难，稳定重复难 | 今天的成功经验明天就忘了 | 所以真正的命题不是"怎么让 AI 更聪明"。Agent 的价值不是替人做事，是把依赖人的高频工作，改造成可以持续执行、可观测、可复盘、可优化的系统。 人是瓶颈。但解决瓶颈的方式不是让 AI 替代人，而是让系统不再依赖人的实时在场。 想明白这件事之后，我开始动手。但在造系统之前，我先学到了一条最重要的原则。

工程建议： 如果你现在也在手动管多个 AI 终端，先别急着造系统。先记录一周：哪些操作是重复的？哪些切换是可以消除的？瓶颈清单比技术方案更重要。 你现在同时开几个 AI 窗口？上限是多少？评论区聊聊。

第二章：80% 的 AI 需求不需要 AI¶

我开始认真折腾 AI 的时候，第一件事不是去调模型、搞 RAG，而是写了一套 Bash 脚本来自动化日常工作流。结果发现—— 80% 的"AI 需求"，根本不需要 AI。 自动拉取代码跑测试？Bash。定时检查服务健康状态？ cron + curl。把 JSON 日志格式化成报表？ jq + awk。文件变更触发构建？ inotifywait + shell。这些东西不需要任何模型，10 行脚本就搞定了。

#!/bin/bash
# 例：定时健康检查 + 告警，不需要任何 AI  
while true; do
  status=$(curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health)
  if [ "$status" != "200" ]; then
    curl -X POST "$WEBHOOK_URL" \
      -d "{\"msg\": \"API health check failed: HTTP $status\"}"
  fi
  sleep 300
done

这让我提炼出后来最重要的一条原则：

代码优先于 Prompt。能用 10 行 Bash 解决的，别折腾 AI。听起来像废话？但你去看看市面上多少项目，明明一个 cron + curl就能搞定的定时数据采集，非要套一层 LangChain，加个 Agent 循环，搞个 tool calling，最后效果还不如写死的脚本稳定。这个认知后来演化成了一个决策层级： 目标 → 代码 → CLI → Prompt → Agent。 | 层级 | 适用场景 | 示例 | 不确定性 | |---|---|---|---| | 目标层 | 想清楚到底要解决什么 | 想清楚后发现不需要写代码 | 最低 | | 代码层 | 确定性逻辑 | if/else、正则、模板引擎 | 低 | | CLI 层 | 组合现有工具 | grep + jq + curl串流程 | 中低 | | Prompt 层 | 需要语义理解和判断 | 需求翻译、文案生成 | 中高 | | Agent 层 | 多步推理、动态决策、循环执行 | 自动修 bug、端到端流程 | 最高 | 每往上一层，不确定性增加一个量级，成本也增加一个量级。原则很简单： 能在下层解决的，绝不上推。 能用 10 行 Bash 解决的，别折腾 AI。这不是反 AI，是尊重工程。 工程建议： 拿到一个新需求时，从表格最底行往上看——先问"10 行 Bash 能搞定吗？"，再问"一次 LLM 调用够吗？"，最后才考虑 Agent。这个习惯会帮你省掉 80% 的过度工程。 你团队里有没有"明明脚本就能搞定，偏要上 AI"的项目？说出来让大家乐乐。

第三章：Vibe Coding 翻车记¶

知道了"什么时候该用 AI"，接下来就是动手造系统了。但在造出正经系统之前，我先翻了一次车。 24h 打工人项目初期，我也尝试过 Vibe Coding：不写 spec、不做设计，直接跟 AI 说"帮我做个 XXX"，然后看着它一顿操作猛如虎。下面是真实时间线：

Day 1-3    ✨ "wow 这 AI 真厉害"
                   几句话出一个完整页面，说需求就能跑通流程
                   产出速度惊人，成就感爆棚
Day 7      ⚠️ 代码开始乱了
                   AI 对功能的实现越来越差
                   陷入"打地鼠"——修了这个 bug 冒出那个
                   告诉它"这里有问题"，它改了之后引入两个新问题
Day 14     🔥 被迫亲自打开每个文件浏览
                   大量过度设计、冗余逻辑
                   三层抽象解决一个本该一个函数搞定的问题
                   重复的工具方法散落在五六个文件里
Day 15     🔧 整整一天"设计与实现对齐"
                   把 AI 写的代码和手写的设计文档一一对照
                   逐个重构，这一天比前两周加起来都累
                   但这一天的价值，也比前两周加起来都大

Vibe Coding 的问题本质很简单：它是"先易后难"。前期省掉的设计时间，后期会以 10 倍的 debug 时间还回来。代码越写越多，AI 的上下文越来越混乱，每一次修改都在给系统埋雷。 SDD 恰好相反。写 spec 很慢，做设计很枯燥，但一旦 spec 写清楚了，后面的执行、验证、迭代全都有据可循。大路平坦宽阔，但人偏偏喜欢走捷径。Vibe Coding 就是那条看起来省事的小路——走着走着就发现，路越来越窄，荆棘越来越多，最后还得退回来走大路。 Vibe Coding 是先易后难。SDD 是先难后易。大道如夷，而民好径。 Day 15 那一天的"设计与实现对齐"很痛苦。但正是这一天，建立了让系统后续能自动运转的全部基础——设计文档、架构约束、SDD 流程。没有这一天，就没有后面的 24h 打工人。

工程建议： 如果你现在正在 Vibe Coding，享受前几天的快感没问题，但第三天就要开始补 spec。越早补，代价越小。哪怕只有三段话——要做什么、不做什么、怎么算完成。 你 Vibe Coding 翻车过吗？最后是怎么收场的？

第四章：24h 打工人——第一个真正的系统¶

翻车之后，我重新来过。这一次，先设计再动手。场景是这样的：用户提了个 bug——"搜索结果列表的分页有问题，切换页码后数据没更新"。半小时后，AI 自动完成了分析需求、生成技术方案、拆解任务、并发执行前后端代码修改、通知我 review。不是 demo。不是手动跑了五遍调通的演示。是一个真正能 24 小时无人值守运行的系统。我叫它 24h 打工人。

为什么选 CLI 而不是 API¶

先说一个很多人会问的问题。答案不是教条，是阶段性选择。在我当时的场景里，codex、gemini-cli、claude-code 这些工具已经内置了读文件、改代码、跑命令的能力。它们本身就是完整的 Agent——有上下文管理、有工具调用、有错误处理。我要做的不是重新造一个 Agent，而是造一个"管理 Agent 的调度层"。

在我当时的阶段里，CLI 是最低成本、最容易 debug、最利于 AI 直接读取和修复的方案。这不是在论证"CLI 一定优于 API"。等哪天我需要更细粒度的控制、更低的延迟、更高的并发，会毫不犹豫切到 API。工具是手段，不是信仰。

自建调度层：核心架构¶

核心架构四个字就能概括：文件 + 轮询。

维度	Task-Driven	Goal-Driven
人的角色	项目经理 + 执行监督	目标设定者 / 审核者
Agent 的角色	执行器	自主推进者
决策中心	在人脑子里	在目标 + 边界 + 系统状态里
主要成本	人持续编排	前期建模和约束设计
适用场景	简单、一次性任务	长期、复杂、持续推进任务
简单说：Task-Driven 解决执行问题，Goal-Driven 解决迭代问题。前者让系统开始能跑，后者才让系统开始能持续向前。

十年老技术开发的 AI Agent 探索之路¶

Ch04.019 十年老技术开发的 AI Agent 探索之路¶

十年老技术开发的 AI Agent 探索之路¶

第一章：起点——人是瓶颈¶

第二章：80% 的 AI 需求不需要 AI¶

第三章：Vibe Coding 翻车记¶

第四章：24h 打工人——第一个真正的系统¶

为什么选 CLI 而不是 API¶

自建调度层：核心架构¶

SDD：让 AI 的每一步都有据可查¶

智能并发策略¶

工具失败自动切换¶

第五章：Agent 自己修了自己的 bug¶

第六章：从 demo 到系统——门槛不是模型，是治理¶

Observability：6 个必看维度¶

Eval：4 个持续校准问题¶

Control Plane：权限、边界、审计¶

脚手架 > 模型¶

Agent 系统的 5 层地基¶

第七章：协议层正在成形¶

Responses API：runtime 在收敛¶

MCP：工具接入标准化¶

A2A：多 Agent 怎么协作¶

我的判断¶

第八章：从 Task-Driven 到 Goal-Driven¶

Task-Driven vs Goal-Driven¶

Goal-Driven 的 5 个前提¶

共享状态：STATE.yaml¶

6 步落地路径¶

结语：增强自我，而非取代自我¶

深度分析¶

1. 核心矛盾的本质：注意力稀缺 vs 并发需求¶

2. 层级决策体系：最重要的原则性框架¶

3. Vibe Coding 的教训：省事路径的必然代价¶

4. 自举的前提是架构约束¶

5. 脚手架 > 模型：反直觉但成立的投入回报模型¶

6. Goal-Driven 的本质：把人从任务供给中解放出来¶

7. 协议层收敛的行业意义¶

Related entities¶

实践启示¶

立即可执行¶

中期建设¶

长期演进¶