大家一起见证 AI Agent 在今年的大爆发，与以往的移动互联网，应用商店一样，这是我们正在经历的新一波浪潮。借用 HubSpot 创始人对 AI Agent 的定义，AI Agent 就是一种有人工智能大模型参与的，可以执行多步骤任务的一种软件。
我们要重视它，但也无需将它神话，了解它最直接的方法，就是亲自动手实现一下，今年的独立开发者训练营会跟你一起完成 AI Agent 实践，成为一名 AI 应用工程师，也为现在所有行业各个领域的智能化改造做好准备。
套壳
Wrapper，也就是所谓的 “套壳”，指的就是简单的在大语言模型（LLM）外面加了一层包装，比如定制一下系统提示词（system prompt），再定制一下用户界面，包装成一个独立的 AI 应用。有些人会认为这种应用没什么技术含量，很容易被复制，没有护城河（moat），随时可能被干掉。
用工程师的思维得出这样的结论，一点毛病没有，但如果用创业者的思维考虑，套不套壳是无所谓的，因为所有的东西都可以看成是另一种东西的套壳版本，关键还是得看这个东西有没有用，能不能帮助用户解决他们在乎的问题。现在如果用套壳这个词形容别人的产品，还是有点蔑视的语气，不过我认为这个词以后可能会变成中性，可以用来自嘲。
竞争
竞争，也就是我们常说的“卷”，咋说呢，就是现在任何地域都不存在不卷的市场了，今天不卷，可能明天就卷了，竞争是必然存在的，既然我们无法控制，那就只能接受“卷”的事实了，创始人装也得装出钢铁般的意志，没啥好怕的，大家就一块儿卷吧。
有同学说卷也不怕，就怕大厂抄袭，这个想法有两个假设，第一就是大厂必然抄袭，第二是抄袭必死。能被大厂注意，那说明你的产品做的已经非常好了，那也就没啥好害怕的了，而且极有可能他们会先考虑要收购你，有位朋友的产品就是这么被大厂以千万价格收购的。另外，“抄袭” 也可能不是故意为之，很多显见意见的问题，大概率大家都会想到一块儿的。
“抄袭必死” 这个假设就是一但被大厂复制，自己的产品必然会死。这其实也是多虑的，因为现在谁也无法做到完全地垄断，就是无死角覆盖到所有用户。想一下全国有多少家火锅店，某个城市有多少家，甚至一个商场里有几家。大家的口味不同，风格不同，地域不同，定位到的人群也就不同，软件产品也是一样的。
另外，作为小团队或是个人独立开发者，可以先设定一下我们期望得到多大的市场，多少用户，要做多大的营收。很有可能千八百的用户就足够了，甚至做 toB 产品的，有几个用户就能养活整个团队。所以，一个亿以下的生意，咱就别想太多了，干就完事儿了。
市场
确定自己要做一个亿以下的生意，那就不做通用型的软件产品，可以找一个垂直领域细分市场里的某个分类下面的某个特定的用户群体，再确定一个具体要解决的问题。不过这对于工程师来说，还是有难度的，大家平时很难接触到工作以外的领域。有几个方法可以尝试一下，一是采访身边各个领域的亲戚朋友，最好实地观察一下他们平时的工作，二是当卧底找一份相关的工作，三是找个领域专家做搭子。
还有一个方法，就是对老旧臃肿但有长期巨额营收的应用进行改造，只需要确定其中一个核心的功能，加入 AI，进行重建。比如 CalAI 这个 App 就是对 MyFitnessPal 的 AI 重构，MyFitnessPal 距今已有 16 年历史，目前能做到年度 $1 亿的营收，而 CalAI 发布至今不到一年，今年可以做到 $2400 万的年度营收。
模型
模型（model）指的就是人工智能大模型，模型的品种还挺多的，有处理文本的，也有处理图像、音频或者视频的。这些模型一般就是在模型提供商那里，由一帮科学家与工程师用各自的道道训练出来的，通常会以接口的形式对外提供这些模型的能力，作为创业者或者工程师，我们可以在自己的应用里，通过请求这些接口来使用这些模型提供的能力，比如处理文本、音频或是视频。
像是 OpenAI，Anthropic，DeepSeek 这些都是模型的提供商，要使用它们提供的人工智能大模型（GPT，Claude，DeepSeek R1 …），可以先在他们那里申请一个账号，买点积分（credit）就可以了，一般都是按使用量来计费，比如按处理的文本数量计费，这个数量的单位叫 token，所以你会发现很多模型提供商会告诉你，每百万个 token 的费用是多少。
应用
你写好一段文本指令（prompt），把它发送给大语言模型的接口，这个接口会根据文本指令生成一些内容，这其实就是一个 AI 应用。软件工程师、创业者要做的事情，就是利用这些已有的大模型提供的能力（比如文本的提取、分类、分析、生成 …），为某个细分市场的用户群体解决实际的问题。
这段交给大语言模型处理的文本指令，就是提示词，英文叫 prompt，编写文本指令这个活就是所谓的提示词工程。写出好的提示词，得有领域专家的辅助，也可以借助提示词生成工具或是搜索提示词模板。我们只需要先掌握提示词的基本框架就行，然后通过大量的测试，不断地优化，最终得到自己想要的结果。
在提示词中可以给大模型分配一个角色，告诉大模型它是谁，能做什么，不能做什么，用最简单直接的语言描述清楚具体的任务，说明输出的格式，长度，内容的风格，可以让大模型先思考，然后再生成内容，在提示词中提供一些示例数据，使用自定义的 xml 标签把复杂的提示词拆分成不同的部分，这些都可以帮助大模型理解你交给它的任务。
上下文
现在大语言模型还没办法记住我们之前都跟它交流过什么，所以我们可以说它是无状态的（stateless）。比如你想让它知道当前的用户是谁，之前都跟它聊过什么，用户的订单历史等等，那就必须要把这些信息放到提示词里，一块儿再发给大模型去处理，这些信息就是上下文（context）。
比如我们可能会把用户与模型之间的对话历史放到数据库里保存起来，这样每次与大模型对话的时候都会带着一定数量的对话历史，在一些 AI 应用架构里，会用记忆（memory）这个词来表示这个功能。这些记忆（对话历史）也可以看成是一种上下文信息。
如果说上下文信息过于旁大，考虑到成本与大模型的能力或者性能，一般我们会把这些文本用特定的规则切分成小块，然后用向量（vector）的形式来表达这些内容，再把它们存储到向量数据库里。这样在需要的时候，可以通过语义在向量数据库里检索到相关的内容，再把它们作为上下文交给大模型处理，这就是所谓的 RAG 技术，检索增强生成，也就是先检索到相关内容，然后交给大模型来生成内容。
工具
AI Agent 之所以强大是因为它可以使用外部的数据与服务，比如来自各种第三方系统里的数据，像是客户关系管理系统，项目管理系统，人力资源管理系统，各种内容管理系统等等，或者有些任务可能需要用到搜索引擎搜索到的结果，或是获取到实时的股票价格，天气情况等等。
调用外部系统里的数据，使用外部系统的各种服务，这些都会以工具的形式集成到 AI Agent，工具（tool）其实就是个包含了功能描述的函数。也就是我们可以定义一些工具，比如集成各种三方服务，然后把这些工具交给大模型使用，其实就是通过工具的描述告诉大模型，它可以使用的工具有哪些，这些工具的功能是啥，这样大模型在处理任务的时候，就会自主决策要执行哪个工具。
比如我们定义了一个可以获得到指定位置实时天气的工具，交给一个 AI Agent，这样当它在处理到需要获取天气情况的任务的时候，大模型就会做出一个工具调用的响应，在这个响应里会包含需要调用的工具，还有调用这个工具的时候需要的参数，这样在我们的应用里，可以根据这个响应里的数据（工具的名字与参数值），调用对应的工具，也就是执行特定的函数，再把工具返回的结果作为上下文再次交给大模型去处理，这样大模型就会根据这个工具调用的结果来生成合适的内容。
AI Agent
知道如何编写提示词，如何让大模型拥有记忆，如何检索相关的内容，如何使用工具，这些就是构建 AI Agent 的基础零部件，也就是其实写几行代码就可以定义一个 AI Agent，也并不需要用到复杂的应用框架，知道如何定义函数，调用接口就完全可以创建 AI Agent 了。
AI Agent 的核心就是它可以自主进行决策，也就是用大语言模型，替代了以往需要硬写到应用里的逻辑或者需要人工参处理的事情。至于你想让它干的那些神奇的具体的事情，还是需要我们开发者自己来写，或者使用三方提供的工具，比如你想让它搜索 Web，就得给它提供一个能够搜索 Web 的工具，或者使用 exa.ai 之类的三方服务作为它的工具，这样它才会有这个搜索全网的能力。
工作流
工作流（Workflow），就是用来编排复杂的一系列操作用的东西，它也是 AI Agent 系统里的一部分。在一些 AI Agent 应用框架里，会使用图式（graph）关系来表达在工作流里的不同的步骤。也就是我们可以把一个复杂的任务拆解成小块，再把它们用一种类似系统流程图的形式表达出来，只不过作为开发者，我们是用代码的形式把它写出来，基本就是先干啥，再干啥，完成以后再干啥，发生什么事情的时候干什么事。
在 Anthropic 写的 “Building effective agents” 这篇文章里介绍了几种常用的工作流的设计模式，在这次独立开发者训练营里，我们会一块儿手工实现这几种工作流。
提示链工作流
如果一个任务可以清晰地分解成多个步骤，可以使用这种工作流。
假设我们是一家 SaaS 公司，需要根据用户的反馈，生成改进的建议。这个任务可以分解成几个步骤，第一步：可以根据输入的一组用户反馈，提取出反馈的日期、用户、类别还有描述，第二步：把反馈按照类别进行合并，统计每个类别的反馈数量，第三步：对类别进行排序，最后根据每个类别生成改进的建议。
路由工作流
根据用户的输入，动态地选择不同的路径来处理用户的请求，也就是我们可以选择特定的提示词或者模型来处理不同类型的请求。
智能客服系统就非常适和使用路由工作流这种模式来设计这个 agent 系统，比如用户的反馈可能是要退货，遇到技术问题，或者只是简单的咨询，根据用户的这些反馈的类型，使用对应的 AI Agent 来处理，这些 Agent 可以使用不同的提示词，大模型还有工具，这么做的好处就是可以提高处理不同类型请求的效率还有质量。
评估优化工作流（Evaluator-Optimizer）
通过迭代生成与评估解决方案来逐步地优化最终的结果。在这种模式里面，会有一个生成内容用的东西（生成器），还有一个评估内容用的东西（评估器）。生成器负责生成内容，这个内容会交给评估器进行评估，如果评估的结果不符合要求，就会提出反馈，再交给生成器进行优化，然后再次生成内容，直到评估器认为结果符合要求为止。
编排工作流（Orchestrator-Workers）
这种工作流里有一个编排器，还有一个 worker。编排器可以根据用户的任务，动态的生成一组子任务，然后再把这组子任务交给 worker 去处理。
比如你想设计一个写作用的 agent 系统，可以根据用户要写的文章，动态地生成一组编写不同风格文章的任务，再把这些任务交给 worker，让它去生成不同风格的文章内容。
总结
我们不用在乎到底用的是什么技术，语言，框架，还是多关注问题本身，用户在乎的是他们的问题有没有解决，效率有没有提高，营收增没增加。作为开发者创业者，我们的任务就是解决用户的问题，至于到底用的是啥，也就没那么重要了。
最后邀请你参加这次的独立开发者训练营，除了掌握构建这些 AI Agent 系统的零部件，我还介绍了一个目前增长速度极快的应用构架，用它可以更快速的实现需求，在训练营我会持续与你共享实战技术。查看介绍，报名参加→。
