上当了，AI 实战的有些弯路根本没必要走！
现在在互联网上搜索AI Agent开发面经，你会得到五花八门的问题。他们从模型数据清洗到某个具体的框架使用细节，从真实案例到开发理论，似乎AI Agent 开发和我所认为的调一调API，写一写Prompt不太一样。
可，事实真的如此吗？
澄清概念
在解决上述问题之前，我们先对齐一下认知。
职位边界
只谈开发岗位，我们说AI 开发岗位大概可以分为三个层级
- 基础设施层
- 模型开发层
- 应用开发层
基础设施层是大模型以及所有程序运行的底座，模型的计算管理，数据管理，服务，监控都归他们负责。这一类要求有架构能力，大模型与硬件线管知识，属于最硬核的。
模型开发层，比较陷阱。我最近买的一本书《实战AI到模型》
我是奔着openAI的背景来学习一下的，目录都没看就下单了。不小心误闯天家了...
从书的目录你可以看到，机器学习、建模、数据清洗准备，模型开发等一系列又一陌生的词汇。但RAG还是通用的，后面的层级也会讲到。
应用开发层。这一层，才是大多数后端、前端人的选择。提示词，上下文工程，记忆。包括到具体LangChain、AutoGen框架细节。
Agent 是什么？
最开始的定义，我们把能自主完成某项任务的程序称为Agent。现在，到没那么严格，甚至有些会称呼Agent为Agentic（严格来说，确实不同）。
所以，更宽泛的来说，只要你开发的程序接入了AI 大模型，都可以称之为Agent应用。
应用开发模式
说到Agent应用，又不得不提到几种方式，业界更专业的说法叫：设计模式
Prompt 工程
这是所有人都要经历的阶段。在早期，模型参数没这么大，质量也不高，不够稍微复杂的问题，甚至无法严格要求输出JSON格式。这个时候，因为重点还是放在模型上，所以我们需要输入给她更多COT（思维链），样本（举例子）。
现在的模型能力强了，降低了Prompt的复杂度，只需要描述的准确，就可以做到一些简单Agent的开发。但这个时候的输出结果还不是很稳定。
Workflow
为了更稳定的输出，降低不确定（大模型），所以人们引入了更多的程序代码来分担模型任务。这个时候分为了两派，一个是Coze、Dify这样的，非程序员也可开发的智能体平台。
另一方是使用LangGraph这样节点与边搭建流的程序员。
单 Agent
在Workflow迸发的同时，还有另一个方向。一个固定的设计流程， 通过让大模型自主安排计划，控制整体上下文，记忆，甚至主动调用已有工具的单Agent工程也在野蛮生长。
多 Agent
还是在Workflow时代，那个时候，人们觉得多一个大模型节点就是多一份不确定。但这个方式的多节点Workflow并不是真正的多Agent。
现在的多Agent是在单Agent基础上，引入不同角色（role）。比如一个开发团队，有产品，开发（前后端），测试，运维。
将整体功能拆解，模型负责的功能更专注，出错的可能也就降低了。每一个role有独立的记忆，有自主决策能力，单职责的模型能力更强。
但也并不是毫无缺点，这样一个流程将会特别耗时，Token的消耗也巨大。
不要设计过头
和架构设计选择单体还是微服务一样，不是所有场景都要多Agent
如果你想应用毫秒级返回结果，目前的大模型不适合此任务
如果复杂度不高，不确定性也可以接受。比如给标题定分类，Prompt就够 如果复杂度很高，不确定性几乎没有，工作流更适合此任务。比如短剧脚本。
#AI求职实录#尽量让所有人都可以认识，并且使用大模型
查看9道真题和解析