很多人卡在一个概念误区上：什么是代理？什么是基础设施？

说直接一点：代理是你看到的智能行为，基础设施是背后那堆干脏活累活的机器。当你嘴上说"我做了一个代理"，真实情况是，你写了一套基础设施，然后接了个模型。模型本身不会变成代理，代理是行为涌现的结果，而基础设施是让这种行为发生的物理条件。

这个区分很重要，因为它直接决定你的优化方向。如果你一直盯着模型调参数，那你是在调演员。但真正决定演出质量的是舞台、灯光、剧本和调度系统。演员再牛，舞台塌了照样完蛋。

原文给了一个非常精准的类比：大语言模型就像中央处理器，没有内存、没有磁盘、没有输入输出，它甚至不知道世界存在。上下文窗口是内存，外部数据库是硬盘，工具是驱动程序，而基础设施就是操作系统。这不是比喻，这是结构等价。

你买了台顶级 CPU，然后放在纸板上通电，最后怪 CPU 跑不动游戏。模型就是那个 CPU，它连今天星期几都不知道。所有的记忆、工具、流程控制，都是基础设施给它装上的假肢。

更扎心的是，很多工程师花几周时间调提示词，却不愿意花一天时间好好设计工具调用和错误处理机制。结果系统在演示时像个天才，一上线就像个白痴。然后怪模型太垃圾。

围绕模型，一共有三层工程结构，每层控制不同维度：

第一层：提示词工程。 负责"说什么"，也就是输入指令设计。大多数人停在这一层，觉得自己是提示词大师。

第二层：上下文工程。 负责"什么时候看到什么"，也就是信息调度。少部分人理解这一层，开始设计记忆和检索。

第三层：基础设施工程。 这是全局系统，包括工具调用、状态管理、错误恢复、安全机制等。真正决定系统上限的是这一层。

绝大多数 agent 项目失败，不是因为模型不够强，而是因为第三层根本不存在或者写得像坨屎。对话两三轮之后上下文就乱了，模型开始答非所问；工具调用十次有三次解析失败；错误信息直接塞回给模型，模型看不懂反而开始输出"抱歉我遇到了错误"之类的废话。这就是典型的基础设施坍塌。

反过来看，那些表现稳定的 agent，往往模型很普通，但基础设施设计得非常扎实。它们有清晰的状态机、严格的错误分类、完善的日志和恢复机制。

整个 agent 运行的心跳是一个循环：思考、行动、观察。听起来像个 while 循环，确实就是。但真正复杂的不是循环，而是循环里管理的一切。

这个循环最搞笑的地方在于，很多工程师非要往里面塞各种花哨逻辑。在循环里加一堆条件判断、状态缓存、优先级队列。结果模型还没开始思考，基础设施就已经把数据搞乱了。

正确的做法是：让循环保持简单，只做机械的搬运工作，不做任何智能判断。循环只负责三件事：把信息喂给模型，等模型输出，执行模型要求的动作。其他所有事，比如记忆压缩、工具注册、错误恢复，都应该在循环外面处理。你越想把智能塞进基础设施的判断逻辑里，系统就越蠢。

原文还有一个设计哲学值得提：基础设施像建筑脚手架，帮助构建，但最终应该被移除。随着模型变强，基础设施应该变薄。

想象一下，你为了盖一栋楼，搭了极其复杂的脚手架。楼盖好了，脚手架不拆，反而继续加装电梯、空调、霓虹灯。最后整条街的人都来看脚手架，没人注意那栋楼。这就是很多 agent 项目的现状。

模型本来可以自己处理记忆了，你还在用外部向量数据库。模型本来可以原生调用工具了，你还在写解析正则。模型本来有超大上下文了，你还在做压缩。你加的这些基础设施，不是帮助模型，而是限制模型。

正确的演进路径是：模型能力弱的时候，基础设施厚。模型能力变强，基础设施就变薄。每隔三个月，审视一下你的基础设施，问问自己：哪些东西现在模型自己能做了？然后删掉。删不掉的是核心，删掉的是过度工程。

工程实践中必须做七个选择。每个选择都有代价，没有标准答案，只有权衡：

1. 单代理还是多代理
2. 思考-行动-观察循环还是计划执行
3. 上下文管理：全量还是压缩
4. 验证机制：规则还是模型评判
5. 权限控制：白名单还是黑名单
6. 工具数量：多而全还是少而精
7. 基础设施：薄还是厚

总原则：从简单开始。先用单代理、思考-行动-观察循环、全量上下文、规则验证、白名单、少工具、薄基础设施。跑通了再优化。别上来就搞核动力航母，结果连港口都没修好。

AI 工程的难点已经不在模型，而在系统。真正的挑战是如何管理上下文，如何设计记忆，如何控制错误，如何构建验证，如何平衡复杂度。如果你的 agent 失败，不要怪模型，先看看基础设施是不是一团糟。

好消息是，基础设施是可以学习、可以改进、可以量化的。你不需要发明新的模型，只需要把现有的工程原则应用到 agent 系统上。状态机、错误分类、日志、监控、回滚，这些传统软件工程几十年的积累，在 agent 时代依然有效。因为 AI 是概率性的，确定性的工程手段反而变得更加重要。