跳转到内容

第 39 节 · 总复盘:从 Token 到 NPC 的全链路

一根线串起 7 天

Day1 · LLM 本质
  "给定前面的 token,预测下一个"
 概率采样 / 涌现 / 幻觉 / 天生边界

Day2 · LLM 行动
  "光说不干不是 Agent"
 Function Calling / ToolRegistry / 最小 Agent Loop

Day3 · 教它怎么想
  "不同范式适合不同任务"
 ReAct(边想边做)/ Plan-and-Solve(先规划再执行)/ Reflection(自我审阅)

Day4 · 让它记住事
  "对话超过 30 轮就爆窗口"
 ContextManager(压缩)+ Memory(embedding + cosine 召回)

Day5 · 给它工具箱
  "Coding Agent = 五阶段循环 × 安全工具"
 read / list_dir / write / edit / bash + 设计哲学(old/new / 4 道闸门)

Day6 · 组装
  "120 行把 6 个零件拼起来"
 CodingAgent + REPL UI + 3 个真实任务

Day7 · 上线
  "你的 Agent 变成团队里的 NPC"
 Skills 热插拔 + Docker 打包 + CNB Pipeline + NPC 回复

回顾要点

每天一个"灵魂问题"

灵魂问题一句话答案
1LLM 为什么能写代码?它不"理解"代码,它只是在做 next-token prediction,但规模够大时"涌现"出了编码能力
2Agent 跟 Chatbot 有什么本质区别?Agent 有循环——能调工具、看结果、再调,直到完成任务
3ReAct 和 Plan-and-Solve 什么时候选哪个?信息不确定时 ReAct(边走边看),步骤明确时 P&S(一次规划省 token)
4为什么不把所有对话都留着?token 贵 + 模型注意力 U 形衰减——必须压缩/摘要/分层
5edit 为什么用 old/new 不用行号?LLM 上一轮读到行号,下一轮再用时行号已经变了
6CodingAgent 为什么只有 120 行?因为 6 个零件各自接口简单、职责单一,主逻辑只是粘合
7NPC 上线最容易挂在哪?glibc 版本不对齐 / Secrets 没配 / settings.yml 里 NPC 名拼错

知识地图

┌───────────────────────────────────────────────────────┐
                    CodingAgent
├──────────┬──────────┬──────────┬──────────┬──────────┤
   LLM  Tools Context  Memory   UI
  (Day1)  │ (Day2+5) │  (Day4)  │  (Day4)  │ (Day6)  │
├──────────┴──────────┴──────────┴──────────┴──────────┤
  Agent Loop (Day2) + 范式 (Day3) + Skills (Day7)     │
├──────────────────────────────────────────────────────┤
  Docker + CNB Pipeline + NPC (Day7)                   │
└───────────────────────────────────────────────────────┘

你做出来的东西,跟行业差多少?

能力你的 AgentCursor / Claude Code
读写代码
多轮工具调用
上下文管理✅ 基础分层✅ 更精细的索引 + 多 Agent
长期记忆✅ 余弦召回✅ + 向量数据库 + 用户画像
Skills / Rules✅ SKILL.md✅ 更丰富的触发机制
安全沙箱⚠️ 黑名单✅ Docker / gVisor / Firecracker
多模型路由✅ 大模型规划 + 小模型执行
并行工具调用
代码索引✅ tree-sitter + 向量化
用户体验⚠️ CLI✅ IDE 深度集成

结论:核心架构 80% 一致。差距在于工程打磨(并行/索引/沙箱/UX),不在概念层。

课后你可以继续做什么

见 README 的"课后路线建议"部分。

Released under the MIT License.