[post] vibe coding 与编程 Agent

（待完善）

Agent = Model + Harness

Agent 本身的原理，以及如何更好的使用如 claude code，codex，open claw

自然语言会是新的 Shell 吗？

背景

网页聊天

ChatGPT 像一个“专家问答窗口”，用户输入自然语言，模型返回自然语言。

生成式预训练大模型 GPT，NLP 的技术路线从为每个任务单独训练转向预训练大模型 + 微调/提示。

https://openai.com/zh-Hans-CN/index/chatgpt/

2022 年 11 月 30 日，隆重推出 ChatGPT，3.5。能对话，写文章，回答追问，这个时候，这个时候的模型已经比较厉了，但是还是能看出来车轱辘话来回讲。

2023 年 3 月，GPT-4 出来，AI 真的能做些事情了。

2024 年 5 月 GPT-4o，免费用户能体验到的最先进的模型。

通过 api 与 llm 对话

关于 LLM API，2020 年 6 月，GPT3-API

https://openai.com/zh-Hans-CN/index/openai-api/

api 比网页对话问答更接近模型一些，早期的 GPT3 模型就已经有 API 的调用接口了，将大模型集成进软件工作流的尝试也开始了。

大模型，大语言模型，文本进文本出，字符串进字符串出。

其实和 unix 的 cli 工具如 ls ，在外部视角看起来没什么区别 ls /dev

/dev 是一个字符串，argv[1] 的类型为 char*，终端显示的东西，都是 printf 出来的字符串。write(1，)

用比较高的视角来看，这些工具也是 stdin 计算之后 stdout，只不过是专用的工具，并且是靠近计算机的语言，不是严格的C这种的，对于非程序员来说也不是完全可读的。

关于 MCP 与 CLI 的讨论的来源，即 CLI 思路就是文本进文本出，天然契合 LLM

那么可以做一个程序，在 API 外面封装一层很简单的代码，接受终端的字符串进，然后输出计算过后的字符串。

作为提示词给 codex 几分钟就能实现出来

一个集成到终端的聊天工具

./llm "hello "

curl 快速测 api。C 语言解析，cjson，http请求。go 语言，更好的集成，二进制分发

对 ai 编程来说，如果只关心行为，用什么语言实现也不重要了。

对于终端来说，参数作为输入，管道、重定向，也可以作为程序的输入。组合输入，可以做更多的事情，需要做一些提示词的组装，对 AI 身份的预设，(Prompt Engineering 会考虑的比较周到的东西)

一些典型用法

cat log | llm "总结一下“

cat main.c | llm "解释一下"

已经像是一个集成进 cli 的能用的小工具了。

一次性的使用，组装 rpompt -> 调 api -> 拿结果，展示给用户

LLM API wrapper

输出也进入执行系统？

到此为止，只考虑了进入端的接入。是否可以让 llm 的输出也作为下一个 unix 工具的输入？

让 llm 启动时读一个 System.md，里面存放了 System Prompt，全局行为的约束 (预训练大模型 + 提示)，连同所有的输入，一起组装起来。

这个 System.md 与 CLAUDE.md 或者 AGENTS.md 相同，都是文件名匹配，在启动时加载的。

比如说，System.md 要求，输出可以直接在 shell 执行的指令，并且，不加任何符号包围。

然后，使用一些 shell 的机制，$()

思想实验/最小原型

那么比如 $(llm “创建一个名为 readme.md 的文件”) ，这个整体就真的创建了一个新的文件。

在 LLM 的帮助下，讲几句话，一些东西发生了变化。

当能创建一个文件，理论上读写修改删除都能做到，在 linux 里，能读写文件 = 能做任何事情，比如操作硬件。

claude -p 看起来和 llm 有点像，llm 是 claude -p 的极简版吧，差了非常多的东西。

$(llm "创建一个名为 readme.md 的文件") 是一个思维实验，

当 LLM 的输出不再只是给人看，而是进入 shell，被系统执行时，LLM 就从“回答者”变成了“行动建议生成器”。

mini agent

最小原型缺了非常多的东西

命令执行结果、权限控制、任务状态。。。。

从行动建议到做事情

LLM 直管文字的输入输出，能做事情，依赖了 prompt 和 $()，LLM 的需要有些代码去帮助 LLM 做他想做的操作。

早期，排bug，复制 log 粘贴到网页，然后根据 gpt 的提示，粘贴代码，直到问题被解决。

提要求  ->   LLM  调用工具？  ->  否，做总结输出，结束
      |                   |
       -- 调工具，拿工具结果-

想要用什么，先得让 LLM 知道有什么，因此，工具信息也需要给到 LLM，

每一轮推理的结果，和工作调用的结果，都会附加在前面的内容，做最新的一次推理。

一个万能工具，bash，几乎能做任何事情。

更多的工具

bash 是最高自由度工具，也是最低语义密度、最高风险的工具。

新增 read write 工具，这也是一种封装，

gpio_set，led_set

bash(“gpioset gpiochip0 17=1”) 和 led_set(“on”)

的区别，我也可以去看原理图，知道 gpioset 是 led，但是中间的全是没用的信息。前者需要理解 Linux、GPIO、硬件映射、命令参数；后者直接暴露了“能力”。

让人更好的工作都需要给人提供更顺手的工具。工具设计的目标，不是让 Agent 什么都能做，而是让 Agent 更容易做对事。（工程化补充 MCP）

工程上的实现，工具注册表，

关于权限的问题，调用工具前要考虑的东西，作为一个生产级的程序，应该要关心的

工程上，如何实现？工程审美问题，hooks 机制，主逻辑一眼看清，人的关注力也有限，人还不如 AI，软件上的抽象概念完全是为了照顾人的理解能力。系统做大和还能被人理解，全靠抽象。

Agent 系统最终仍然是软件系统。模型可以处理复杂文本，但系统设计不能把复杂性全部甩给模型。抽象、模块、hooks、权限、日志、可观测性，本质上都是为了让人还能理解这个系统。

使用时遇到了问题

上面的这个已经能用了，核心原理上已经解决了。后面去改善

目标坚定？

大任务，给自己做一个计划表，todowrite，自己慢慢做

todo、plan、checkpoint、阶段验收。Claude Code、Codex 这类工具会有计划、任务列表、子任务、diff review。

一些只需要知道结果，用结果决策的，找一个实习生，临时外包 ，subagent

LLM 性能的限制

context windows，

用到时加载全部，上下文压缩

记忆？内存和硬盘？记脑子里，写笔记本上？

东西越来越多，system prompt 是时候考量一下了。

一些想法

vibe coding 不是编程消失，而是编程活动的重心迁移：从手写每一行代码，转向描述目标、组织上下文、设计工具、约束权限、检查结果。

编程 Agent 也不是魔法。它更像一个新的操作层：LLM 负责理解意图，工具负责改变世界，上下文负责维持状态，权限系统负责控制边界。真正的工程能力，仍然体现在如何设计这个系统。