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

佬友们，周末好，最近比较忙，在忙方向，在忙找团队，在忙工作，在忙项目，现在稍微清晰了一些，所以就趁感觉还在就整理了一些自己的经历和思考

现在我发现学习时间真宝贵，我突然回忆到自己大学去图书馆的学习，有整整一天的时间，没有任何其他的事情打扰，很难得呀，学习时间存在，那么学习方向需要找一下，这个文章是写给大学的技术朋友们，也是写给大模型应用开发工程师们，也是写给过去和现在的自己。

我先说一下，自己这一段时间对于岗位市场的观察是思考，不一定很完整，但是存在的

目前大模型应用开发岗位可能会出现一种现象

前期大批招入，后期大批辞掉

这种情况是存在的，原因我觉得是招聘方“没有想清楚的狂热”，就像openclaw火的时候就有很多岗位出现，仿佛AGI已经到来，大家都赶紧招人进来做，

但是结果我们都知道，声音变小了，其实在openclaw火的时候，其实蛮多开发者心里是清楚的，过于火了，不正常，那确实这种清楚才是正确的

所以大家选择团队的时候，最好去那种有自己思考的，有自己对于agent的认识，有赚钱存活的方式，这种团队相对来说会比较稳一些，也会有效一些

现在我觉得依旧是千军万马过几个独木桥，依旧存在很多可能，不要轻易固化思考和理解

感慨一下吧，要用持久论的理解去思考这些事情，只要我们是不断进步的，终归是能达到你想去的远方的，要在失败中看见成功，也要在成功中看到危险。

我依旧在看机会，如果觉得我可以一起做一些有意思的事情，非常欢迎我们聊一聊

那么进入正文吧！！！

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

上面整理出来的是我自己对于大模型应用开发的理解，也结合了一些技术和概念的变化时间线，仅供各位朋友参考，不一定准确，我觉得大模型应用开发最重要的是这三个东西：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://linux.do/t/topic/2311122/11?u=wakeup-jin


• 大模型学习路线 - #13，来自 WakeUp-Jin


• Agent岗位的工作日常 - #47，来自 WakeUp-Jin

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

对于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工程实践文章：Engineering \ Anthropic

  
  


• 
  

  Claude团队博客：Blog | Claude by Anthropic

  
  


• 
  

  Anthropic的研究文章：Research \ Anthropic

  
  


• 
  

  Cursor团队博客：Blog · Cursor

  
  


• 
  

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

  
  


• 
  

  ClaudeCode的文档：Overview - Claude Code Docs

  
  


• 
  

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

  
  


• 
  

  Pi的文档和源码：GitHub - earendil-works/pi: AI agent toolkit: unified LLM API, agent loop, TUI, coding agent CLI · GitHub、Pi Documentation · Documentation · Pi

  
  

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

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

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

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

1. 
   

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

   
   


2. 
   

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

   
   


3. 
   

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

   
   


4. 
   

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

   
   


5. 
   

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