我是如何学习大模型应用开发的

大模型应用开发的一些概念关系

上面整理出来的是我自己对于大模型应用开发的理解，也结合了一些技术和概念的变化时间线，仅供各位朋友参考，不一定准确，我觉得大模型应用开发最重要的是这三个东西：Agent Loop、Context Engineering、Harness Engineering

最近好像又新出了很多层的概念，在harness engineering之上，但是我个人现在并不喜欢，所以没去做更深入的了解，我觉得新出的很多概念，没有出现新的基础元素，只是融合现有的，然后加深了一下理解，所以我个人的想法是：了解即可，知道有这么个东西就可以

• Agent Loop是运行的核心，是一切的基础，用户输入任务，LLM输出指令，工具执行并返回结果，不断的循环直到结束

• Context Engineering在静态系统提示词结构不断稳固之后，发现Agent Loop在运行中是需要大量的动态信息的，并且常见有效的动态信息是用户记忆、会话历史记录、用户输入、系统提示词、工具定义等，那么这个时候就有了Context Engineering这个概念，上下文是Agent Loop有效的关键，在Agent长程运行中，上下文不断积累，会出现各种各样的问题，漂移、污染、干扰、冲突等，所以我们需要上下文管理的方法，需要渐进式加载的概念

• Harness Engineering是Agent稳定运行的关键，它为Agent搭建运行空间，设计Agent的能力结构、协作机制和反馈闭环，其不能仅仅从约束的角度去理解，更应该是在创造Agent的运行环境，让LLM可以做到原本无法做到的事情

推荐的学习顺序

然后我按照自己的理解，大概梳理一下学习的顺序和方向，给学习的朋友一些“经验之谈”，当然下面的这些概念我都单独梳理过一些文章和实践经验，会搭配一些代码讲解，感兴趣的朋友可以借助这个学习手册来更好的了解

《大模型应用开发 -上下文工程与运行空间实践指南》：https://github.com/WakeUp-Jin/Practical-Guide-to-Context-Engineering

还有一些其他值得多聊的事情，我这边继续补充一些我自己的理解：

对于RAG和知识图谱的理解，我认为这个来源于“背景信息”这一种类型的上下文，我没办法准确的去下定义，我只是有一种淡淡的理解。

用户输入的问题，LLM需要解决，是需要一些背景信息的，有时候用户可以手动补充，模型也可以依靠推理能力去补充澄清，但更多的情况下，LLM需要依靠工具系统去动态的检索到这些“背景信息”，那么检索流程中最关键的手段就是：RAG和知识图谱，我甚至觉得Harness Engineering诞生在Agent领域中，也是因为“背景信息”作为一个突破口出现的。

上下文管理是一个值得深入探索的方向，Agent借助Skill来达到上下文层面的自进化，是一个上下文管理的具体应用，我相信这个里面还有很多有趣的东西，值得去深挖，目前来看比较常见的是：上下文压缩，文件存储检索，上下文编排，渐进式披露等。

在工具设计中，如果要有一层“宗门长老“的概念的话，我觉得是Edit、Bash、Read、Glob、Grep、Wirte这“六位宗门长老”，Bash工具甚至可以是“大长老”级别的。而目前最有难度的是Bash工具运行时的安全和输出问题，而Browser Use和Computer Use是为数不多的有趣的方向了

Agent形态方面，现在还在不断的变化吧，之前大家还会讨论Agent是自主运行好，还是协同驾驶好，现在看来各有各的的领域优势了，在任务确定的领域中，自主运行借助如今的模型推理能力完全可以覆盖住，在创作领域中，协作驾驶还是有一席之地的，用户在Agent输出的产物中，手动的进行各种小微调，同时也可以直观的看到Agent的中间执行链路。

单智能体和多智能体的方式，我觉得单智能体+一个SubAgent的能力，其实就非常好用啦，如果设计成比较纯净的多智能体，成本是可以下降的，但混乱系数会大大增加，不仅对于某些模型的能力要求高，同时上下文管理的难度是指数级上升的，还会添加多智能体协作的概念，这是一个很有魅力的领域，很有挑战的领域。

接下来是我近期最感兴趣的方向了，也是大模型应用开发工程师们最容易忽略的，但在Agent开发中是最重要的，甚至可以说，没有它存在，你的Agent只是一个没有方向的经验产物。

没错，这个东西就是Agent评估，在构建一个Agent之前，或者说在设计一个Harness之前，你需要先存在一批数据集，以此来确定Agent的能力边界和迭代方向，Agent评估在开发中可以帮助你不断打磨提示词、上下文、工具等。

同时在数据集评估的过程中，通过对于执行链路和结果的观察，你会产生一些Agent垂直化的方向，最后你可以通过评估结果来确定它在混乱环境中的运行情况。Agent评估非常值得成为构建的第一步

我的学习经历

我是从24年大学毕业的时候，大概6月份开始学习的，当时第一个需求是批量根据一个固定的提示词生成文章，我当时调用的是百川大模型，当时要毕业答辩啦，所以回了一趟学校，我调试了很久，我记得是在宿舍晚上10点左右调通的，就是一个简单的for循环的API调用，那是第一次看到LLM API的请求格式。

之后在接触到LangChain，里面有一个概念叫做检索器，里面涉及到向量知识库+嵌入模型，当时我们团队有一些语义上的需求检索，所以借助这个机会，我去了解LangChain和向量数据库，在学LangChain的时候，很多概念都非常懵逼，不知道什么意思，封装的在我看来很复杂，当时硬啃了好几天，慢慢的有了一些感觉，LLM供应商的封装，tools方法的定义和使用，链式调用等概念

期间不断了解到各种框架，也在系统性的学习提示词工程，我对于LangChain和LangGraph学的比较多，算是我的入门框架。再后来 Cursor 等 Coding Agent 开始火热，我被 Agent 协同的模式吸引，开始关注工作流编排、工具定义、知识图谱等方向，也用飞书多维表格 + RAG + LangGraph 搭了团队第一个 Agent 项目

在做一个Agent项目的过程中，我形成了自己对于上下文工程的理解，一个Agent是否有效，取决它注入那一刻的上下文是否正确，《大模型应用开发 -上下文工程与运行空间实践指南》这个开源项目也是这个时候开始创建的，我开始深入了解一些技术细节，RAG的检索策略，工具的定义，LLM模块的设计，上下文编排。

同期ClaudeCode、gemini-cli、opencode开始出现，我就开始研究这些开源框架，研究cli 的方式，发现不需要RAG，通过工具形成的本地检索，也就是搜索Agent，随着模型能力的提升，这种方式变得极其有效

这个时候我们团队的第一个Agent项目的V2版本开始迭代了，工作流的方式只能让效果还行，在模型不断提升的能力面前，工作流不仅得不到提升，反而成为了好结果的束缚，开始显露出鸡肋的感觉了，我当时在一篇文章看到“模型应用的开发，要站在模型的同一侧，不要站在模型的对立面”。所以V2版本我们决定采用多智能体+自定义工具设计的方式。

在之后关于如何让一个Agent可以长时间稳定运行的问题开始出现了，一个Agent可以不断的运行多久才会崩溃，上下文会变得极其混乱，这个时候的上下文管理开始慢慢出现了，以此同时Harness Engineering也开始诞生，OpenAI和Anthropic都发布过工程博客的文章，一个是专注于上下文工程和反馈闭环，一个专注于编排，所以我结合这两篇文章，开始构建自己对于Harness Engineering的初步理解，并且后续也在不断的调整

这个时候我也在更深入具体的了解Coding Agent都有哪些工具，这些工具是如何定义的，上下文的压缩策略是什么，指令又有哪些，Skill对于上下文工程意味着什么等问题

现在我的方向是多智能体协作，上下文管理，Agent评估，Harness的自进化，我觉得这几个方向很有意思，值得做更多的探索和学习

还有一个比较有意思的是DeepSeek Harness的一切皆插件的理念，存在着一种可能：Agent Loop可以更换，我很喜欢这一点，它让沉默的Harness仿佛再次焕发生命力，或许可以这么理解，大模型应用开发，一切皆可能，当Agent要面对复杂环境时，静态固定的方式很大程度会失效，开发者不可能在一开始就穷举复杂环境的问题，所以动态自进化的方式是值得尝试的，甚至很可能是一种很好的解法

我的学习资源的推荐

• 飞书里面的通往AGI之路知识库：通往AGI之路

• Anthropic工程实践文章：https://www.anthropic.com/engineering

• Claude团队博客：https://claude.com/blog

• Anthropic的研究文章：https://www.anthropic.com/research

• Cursor团队博客：https://cursor.com/cn/blog

• Lilian个人博客：https://lilianweng.github.io/

• ClaudeCode的文档：https://code.claude.com/docs/en/overview

• LennysPodcast的视频：https://www.youtube.com/@LennysPodcast

• Pi的文档和源码：https://github.com/earendil-works/pi、https://pi.dev/docs/latest

• 我也在做一个相关的开源项目，感兴趣可以看看《大模型应用开发 -上下文工程与运行空间实践指南》：https://github.com/WakeUp-Jin/Practical-Guide-to-Context-Engineering

我对于大模型应用开发的理解

在我自己开源项目中，有2篇我很喜欢的博客，一篇是《两种世界的交互形态：协同Agent与自主Agent》，另外一篇是：《编程 Agent 的工程实践：来自 OpenAI 与 Anthropic 的实战经验》，这个开源项目的理念我觉得也不错：上下文工程是设计原则，Harness是建造目标

在这一大段时间的学习和实践中，我也在不断的想一个问题，对于大模型应用开发来说，什么样的思维和理解是有帮助的呢？

我稍微整理了一些想法（谨小认知，仅供参考）

1. 务实的品质可以让大模型应用开发工程师走的更远，做的更多，务实让开发者不困于“过度冗长且孤立”的思考中，可以寻找到简单有效的解决方案

2. 像你的Agent一样思考，借助执行日志，观察上下文工程的设计缺陷，观察Harness的运行漏洞

3. 人类观察Agent的行为很重要，Agent观察人类的行为也很重要

4. 「Lead, don't follow」去从第一性原理思考事情的本质，去发现和构建新的东西

5. 不要轻易放弃底层技术的学习，它们会极大的给你提供新的视角，要学会站在巨人的肩膀上

我是 WakeUp-Jin，目前在做两件事：

1. 整理一套上下文工程与Agent Harness实践指南 —— 上下文工程是设计原则，Agent Harness 是构建目标
2. 开发 Actspace Agent—— 一个本地 Agent 桌面应用，从 Coding Agent 开始，最终愿景是彻底释放模型能力

GitHub: https://github.com/WakeUp-Jin