立党 2026 年版的 AI/agent 学习路线 YouTube 视频。强观点、面向大学生和非程序员两类受众,给一套从「选模型」到「手写 agent」到「摸清能力边界」到「找对场景」的实操建议。
1. 选模型:普通人别买最贵的
- 别无脑订 OpenAI / Anthropic。日常 agentic coding,85 分和 95 分模型没有显著差异
- 中国大陆推荐买国产 coding plan:智谱、月之暗面(Kimi)、阿里、DeepSeek、MiniMax、快手等,一碗水端平,性价比高
- 比喻:难题(陶哲轩级数学)才需要 95 分;写个全栈 app 这种「初中数学题」,80-90 分模型够用,普通人感知不到差距
2. 学 agent 第一课:手写一个 minimum SWE agent
当代计算机 / AI 专业学生的第一节课、第一个作业。不写就「大学白读」。
- 类比古早计算机系学生爱手搓:Lisp 解释器、操作系统、数据库、JS transpiler……现在该手搓的是最小 coding agent
- 要自己实现的核心功能:task scheduling / 拆分、loop 与流程控制、用户输入、prompt 拼接、function calling / MCP 喂入、output parser、执行(terminal/bash、HTTP req/resp)
- 最小 SWE agent = 只有 terminal 执行 + 文件读写
- 三步法:① 参照 Codex / Claude Code 怎么写(课本/最佳实践,不是抄)② 自己设计 ③ 实现并通过测试
3. 完善 agent:从马车看高铁
实现了第一版(马车)后,对照现代开源/闭源实现(Codex、open code、Kimi code)看差距——看不懂 rust 就让 Claude Code/Codex 帮你读 codebase。要看懂的现代机制:
- long-term memory(含每个 sub-agent 的)
- multi-agent / sub-agent 调度、状态读取、管理
- background tasks 管理(后台十几个 terminal)
- skills / plugins:一堆 markdown,靠 title + description 在正确时机 pick up
- context auto compression(上下文过长的手动/自动压缩)
- loop / workflow 控制(不是无限 loop,要会判断何时停)
- sandbox 环境(Docker 启停、监控、参数控制)
- MCP 自由配置
- 可视化 / 可观测性 + TUI 设计(哪些给用户看、哪些别给看)
先学懂这些再谈创新。
4. 非程序员的「灵丹妙药」:headless Claude Code + temp folder + JSON
他称之为「价值 10 万 / 30 万刀的想法」,高中生都能干:
- 给 Claude Code 绑银行卡
- 建一个 temp folder,把任务相关的一切丢进去:文档、表格、报表、图表、SQLite/Access、PDF 扫描件、Markdown、代码、图片、指令 prompt、config、skills
- 写个 Node/Bun/Python 脚本,从 terminal 调 Claude Code headless 模式,
--dangerously-skip-permissions全开权限 - 状态/输出存进一个 JSON file(成功失败都更新)
- 配好 auth + MCP,让它自己跑(一分钟到很久不等),进程结束读 JSON → 下一步
核心主张:别为每个小领域(蔬菜水果销售 / 算账 / 防盗门)单独搭 agent。把 agent 抽象成「一个有人格、有解决能力、能自动办事的人」——通用 agent + 足够上下文/数据 + 够强模型就能解决几乎所有问题。99% 场景通用 agent 胜过自己瞎搭;只有 1% 需要自搭。
5. 摸清 agent 的能力边界
- AI agent 不是神/超人/黑箱,做不了违反因果论 / 信息论的事:证黎曼/哥德巴赫猜想、预测股票/彩票/GDP——人都做不到的,agent 也做不到。拿 agent 当算命,它会硬给答案,但不可信
- 判断 agent 能否解决 = 先判断人能否系统解决:人有合理流程和方法论(只是不愿花时间),才能交给 agent 自动化。前提:① 足够上下文/数据/文档 ② 科学正确的流程,让 agent 照着执行
6. AI agent 的完美舒适区:封闭 + 可验证
四条标准:① 封闭环境 ② 完整运行/编译/模拟/仿真 ③ 无限试错(搜索空间巨大)④ 可精确验证。 他强调这是「(可验证)driven」并自称发明(转录作 "go driven",疑为 eval/verification-driven)。
满足这四条的领域(他说每条都值 1000 万美元):
| 领域 | 为什么是闭包可验证 |
|---|---|
| 编程 | 本地运行/测试/报错/迭代 |
| 数学 | Lean 4 构建证明,本地编译检查(比编程难,但模型会进步) |
| 电子/芯片设计 | HDL(Verilog/VHDL/SystemVerilog)、PCB、EDA 工具,本地 synthesis/RTL/仿真/验证(但仿真≠流片,终须现场测试) |
| 系统级/嵌入式仿真 | 单片机、MATLAB + Simulink(100-200 个 Toolbox,每个 + agent = 一个领域的自动化研究工具,大宝库) |
| CAD/机械 | AutoCAD(用 lisp 操作)、g-code/数控、PLC、工业控制 |
不适合:金融/股市——公开环境、有对手、噪音大、测不了。
7. Multi-agent:何时有用,何时是坑
前提逻辑:用 1000 倍成本换 10-100 倍提升才值得;token 会越来越便宜/快、并发越来越高、模型越来越聪明,所以 multi-agent 是他眼中 agent scaling 唯一可信的方式。但要分场景:
❌ 不适合
- 编程:七手八脚 merge 代码很危险,coding 更适合「一个人单线程走到黑」;1000 个 agent 贡献代码 = 软件工程/项目管理灾难。(连他自己开源的 full self coding 项目、很多 YC 在投的方向,他都说不太适合)
- 串行 multi-agent(MetaGPT 式:产品经理→架构师→程序员→review→QA→回程序员):sequential 串联,效率小于单个 agent 持续工作,只换来上下文隔离
- 公司/团队架构模拟(agent agency、Crew AI、腾讯 WorkBody、飞书类):七嘴八舌、没人管理 = 一团糟。过去 2-3 年公认的「超级大坑」。除非做管理学研究/过家家
✅ 适合
- 大规模并行任务(map-reduce):网页搜索/爬虫、文献、research/调研/survey、数据清洗、并行客服、大规模审核。足够并行、独立可拆分、层层汇总,架构干净
- 做好流程控制和管理的 multi-agent + (可验证)driven(他在 GitHub 开源了,1000+ star)
下一期:用管理学的方式做合理的 multi-agent 管理。
与本 wiki 的连接
印证了 需求驱动的自动化开发工作流 的设计
立党的「agent 完美场景 = 封闭 + 可编译运行 + 无限试错 + 可精确验证」,正是你那套**隔离测试环境(per-worktree DB + 可跑 + seed + 可验证)**在做的事——给「为什么值得花力气把环境做到可验证」提供了理论背书。
与 onevcat 实践 的张力
- 立党:编程不适合 multi-agent(merge 灾难,单线程走到黑更好)
- onevcat:用 3 猫娘并行跑多 repo/多 worktree + argue 多模型辩论
- 不一定冲突:onevcat 的并行更接近「独立任务并行 + 人居中」(贴近立党认可的 map-reduce/管理良好型),而非「多 agent 七手八脚改同一份代码」。argue(多模型交叉验证)也不同于串行 MetaGPT。关键变量是「是否共改同一代码 + 是否有干净的管理/汇总层」
给 Agents 补了 multi-agent 取舍
见 Agents 新增的「Multi-agent 适合/不适合」一节。
元评价
- 风格:强观点、爱自我归因(声称 SWE agent 概念 2023-04 提出、比姚顺宇早;"go/eval driven" 自称发明)——主张本身有价值,归因部分当作个人说法看待
- 最可落地的两点:① 非程序员的 headless + temp folder + JSON 套路(零门槛通用 agent)② multi-agent 的「适合 map-reduce、不适合共改代码/架构模拟」判据
- 可深挖:eval/verification-driven 的具体方法;他开源的 multi-agent + driven 项目(1000+ star)值得后续找来读
来源
- raw:
raw/ai/2026-06-23-lidang-ai-learning-tutorial.md - url: https://www.youtube.com/watch?v=BqF6PUAXY1M(YouTube,含完整 transcript)