自从GPT3横空出世后，大模型、AI Agent的概念越来越火，已经直接或间接地影响了很多人的工作和生活。很多人对大模型的概念还停留在GPT3刚出来时的Prompt(提示词)阶段，认为做AI就是做PE（Prompt Engineering），AI的好坏全看Prompt写的好不好、模型是不是SOTA（State of the art，直白来说就是夯爆了）。但LLM发展了这么多年，从一个拙劣的聊天式助手到如今可以直接根据指令完成一件事的智能体，这其中经过了很多研究和实践，已经沉淀了很多技术和方法论。本文简要列举一些AI Agent发展历程中的核心技术，也包含了笔者的一些思考和实践经验。希望本文对AI感兴趣的人有所启发。
Prompt Engineering(提示词工程): 让大模型知道自己要干什么
作为一个语言模型，早期的大模型呈现给大众的是一个聊天机器人形式，也就是问一句答一句。这时候Prompt(提示词)显得尤为重要，在基座模型一定的情况下，AI的智能程度很大程度上取决于Prompt写得好不好，由此催生出了Prompt Engineering(提示词工程)的概念，专门研究怎么写Prompt，什么场景下写什么样的Prompt更好。
flowchart LR
U["用户目标"] --> P["Prompt<br/>角色、任务、约束、示例"]
P --> M["大模型"]
M --> O["输出结果"]
O --> F["人工反馈与迭代"]
F --> P
Context Engineering(上下文工程): 让大模型获取必要的信息
PE的方式有很大的问题，那就是为了让大模型更加智能，需要输入足够的信息，有时候要给大模型输入很长的Prompt，但大模型的Context Window(上下文窗口)是有限的，也就是在对话里大模型能够记住的内容有限，并且大模型还有Lost in the middle的毛病，导致Prompt越长大模型越傻。为了平衡上下文窗口限制和信息量，又出现了Context Engineering(上下文工程)的概念，专门研究怎么给大模型更好的上下文来使其更加智能。这其中最具代表性的技术就是RAG(Retrieval Augmented Generation)，也就是检索必要的信息喂给大模型。 用更加直白的话来说，RAG就像是有了一个数据库，把一些行业、封闭域的数据存储在数据库里，每次根据用户的查询条件检索召回对应的数据，塞入大模型的上下文，达到输出内容更加完善的目的。这其中涉及到很多技术，例如Query改写、Embedding、Vector DB(向量数据库)等等。总的来说RAG需要解决两个问题：怎么构建索引、怎么构造查询条件。
flowchart LR
subgraph Offline["离线：构建索引"]
D["业务文档 / 私有数据"] --> C["清洗与切分"]
C --> E["Embedding 向量化"]
E --> V["Vector DB / 知识库"]
end
subgraph Online["在线：检索增强生成"]
Q["用户问题"] --> R["Query 改写 / 意图识别"]
R --> S["检索与重排"]
S --> X["组装上下文"]
X --> M["大模型生成"]
M --> A["更贴近业务知识的回答"]
end
V --> S
Context Engineering刚兴起的时候，AI Workflow(AI工作流)开始出现。其实也就是传统后端的流水线/状态机，只不过加入了调用大模型的节点。这其中的代表有Rivet, Coze等。
后来随着大模型Tool Calling(工具调用，类似于回调)的推广，已经不再需要专门做一个数据检索的节点来专门召回数据塞入上下文，大模型已经能够自己调用工具来查询需要的信息。例如很多聊天机器人都能使用联网搜索工具来自我决策需要查询什么内容。由此MCP(Model Context Protocol)开始兴起，这是一种串联大模型和工具的协议，也就是解决大模型和工具之间的通信问题。总的来说MCP给大模型提供了一些信息：这个MCP Server能干啥，请求、响应的Schema是什么，以方便大模型决策什么时候调用、用什么格式调用、怎么解析返回的数据。
到后来随着对大模型易用性、通用性需求的增加，Skill, Memory等技术开始兴起。这些技术使得开发AI Agent的门槛进一步降低。
Skill简单来说是一种能力扩展包，初衷是将某种能力所必须的上下文、工具等打包到一个文件夹，让大模型自己能够根据需求自主调用某种能力。Skill用渐进式加载的方式解决上下文长度的问题，即启动时只将元数据（这个skill有什么用）加载到System Prompt，大模型推理时，如果觉得要用到这个Skill再加载更多内容。Skill的出现，使得很多非专业人士可以结合AI客户端(如Claude Code, Codex, TRAE)和一些成熟的Tool，用自然语言构建自己的Agent。
Skill 的更多知识可以参考：agentskills.io/home
flowchart TD
Start["启动阶段"] --> Meta["只加载 Skill 元数据<br/>名称、描述、触发条件"]
Meta --> Need{"任务需要该能力？"}
Need -->|否| Base["继续常规推理"]
Need -->|是| Load["按需加载说明、脚本与参考资料"]
Load --> Tool["调用配套工具"]
Tool --> Result["完成特定任务"]
Memory是为了解决多轮对话中大模型遗忘历史对话的问题，也就是之前很多人发现大模型没啥记忆，比如多轮对话之后，大模型可能忘记了一百轮前的对话内容。这其实也是受限于大模型的Context Window，初期很多应用直接使用最暴力的滑动窗口方法，也就是只记住最近几轮的对话，之前的全部遗忘。这种方式的用户体验肯定很差。后来又出现了摘要方式，即对话几轮后觉得历史太多了，就压缩出历史摘要（类似于影视剧的前情回顾）；也出现了更高级的方式，即将所有历史写入数据库，需要的时候再去检索历史对话信息（其实类似于RAG）。
flowchart LR
A["无记忆 / 单轮问答"] --> B["滑动窗口<br/>只保留最近几轮"]
B --> C["摘要记忆<br/>压缩历史对话"]
C --> D["检索式记忆<br/>历史写入数据库"]
D --> E["长期记忆<br/>跨会话复用偏好与事实"]
除了这些技术，还有一些方法论用于怎么让大模型产出更好的结果，这些方法论也可以叫Agent设计模式，都是基于研究者的经验和尝试得出来的结论。例如Plan and Execute, ReAct, Reflection, Multi Agent等等。后续笔者也会出一篇文章专门讲讲这些设计模式。
Harness Engineering: 让大模型直接干活
前文提到大模型已经有了Tool Calling的能力，又有Skill, Memory这些挂件，还有一系列设计模式（方法论）。这就约等于一个硅基生命有想法、能用工具、具备技能、有记忆（有些夸大，但意思就是这个意思），已经不满足做一个简单的问答机器人，而是可以直接干活了。由此Harness Engineering(我觉得现在的翻译如“驾驭工程”、“缰绳工程”等都不太好，所以不翻译了)开始兴起，其目的就是给大模型一些约束，让大模型结合一些工具能够真正地直接干活，是目前实现AI Agent最好的技术。
Harness Engineering和上文提到的Prompt Engineering, Context Engineering不是互斥的关系，而是递进的关系，即Harness Engineering是以上所述所有技术的集大成者。Harness Engineering的实现例如OpenClaw, Claude Code, Codex, OpenCode等，就是将大模型关在架构的笼子里，就像人类用水管、电线形成系统来管理水和电，规避掉其中的风险，使其有益的部分来帮助人类。
具体是怎么做的呢，笔者认为其核心就是ReAct+Tool+Context管理+权限管理。
ReAct就是给出指导方法，让大模型根据环境（用户的输入，当前有哪些能用的Tool, Tool的输出结果是什么）做出对应的决策。ReAct整体是一个Loop(循环)，根据每一步的结果去动态决策下一步应该干什么，达到目标之后才结束Loop。
前文已经提到过Tool Calling，就是大模型有调用工具的能力，前提是让它知道在什么情况下用，以及怎么用。广义来说，MCP, CLI, 脚本等都能算Tool，甚至电脑上装的软件也是Tool（OpenClaw就是这么干的）。大模型有了这些工具后，就可以突破一些能力边界，用工具去做一些语言模型没法做到的事情。比如Claude Code就用grep做代码查询。
前文提到，大模型受限于Context Window，所以要做Context Engineering，也就是如何更好地管理Context。目前主流的Harness Engineering管理Context方式其实就是前文提到的memory，现在最主流方式是摘要，也就是将历史聊天记录进行压缩来节省上下文。
还有一点前文没提到的，就是权限管理。由于大模型可能出现幻觉，所以一些高危操作要谨慎交给大模型操作，比如删除文件、修改数据库等。之前就发生过大模型删库、大模型读取用户隐私上传等案例。可以说权限管理是控制大模型风险的最后一道保障，目前的主流做法是在进行工具调用前都会询问一下用户是否给这种权限。
目前Harness Engineering的主流应用场景还是在Coding，因为Coding的评价方式比较客观，比较好迭代，并且可以帮老板节省研发成本。
关于Harness Engineering的具体实践，可以参考OpenCode的源码: github.com/anomalyco/o…
总结
总的来说，从Prompt Engineering到Harness Engineering，一直都在致力于解决一种事情：怎么让大模型能够更好地干活。之前大模型主要用来查询信息和辅助干活，到现在逐渐变成了能直接干活，现在有的还能只给个目标(goal)就让它自己去实现。
AI 应用的门槛正在不断降低。就像许多技术的发展路径一样，曾经复杂的能力会逐渐被封装成工具、协议和 API。对开发者来说，真正重要的也许不再只是“怎么写一个更好的 Prompt”，而是理解这些能力如何组合，如何约束风险，以及如何把它们落到真实业务流程里。
