1. 项目定位为什么我需要一个能嵌进应用里的 Agent 库做 Agent 开发的朋友应该都有一个体会模型调用好解决难的是一整套工程化的事情。我最早做 Agent 项目的时候是在一个 web 服务里手动维护多轮会话状态、自己写工具调用的分发逻辑、还得处理流式输出、超时重试、上下文窗口管理……一套下来代码量非常大而且不同项目之间反复拷贝改起来还容易改出问题。后来我在找方案的时候看到了 Hermes Python 库。它的定位很明确把 Agent 的能力以库的形式嵌进你自己的 Python 应用里而不是要你把整个项目迁移到一个重型的 Agent 框架里去。这个思路我很喜欢——它不逼你改变现有的代码结构而是给你一个可以按需使用的组件。如果让我一句话概括 Hermes 的价值它把我之前在 Agent 开发里踩过的那些坑会话管理、工具调度、上下文控制都封装好了让我可以用几十行代码就把一个具备工具调用能力的 Agent 集成到 FastAPI 服务、CLI 工具或者数据处理流水线里。对于想快速把 Agent 能力产品化的人来说这个库的切入角度非常实用。适用人群我觉得可以分为几类已经在用 Python 做后端开发想在现有服务里增加一个 Agent 入口的正在做 Agent 原型验证不想一开始就引入重型框架的对 Agent 内部机制有兴趣想在一个轻量级实现基础上做二次开发的。说句实话Hermes 不是那种全家桶式的框架它更像是一个精心设计的工具箱。你不需要为了用它而重构你的项目想用哪块拿哪块这是它最吸引我的地方。2. Hermes 核心设计思路解构2.1 Agent 开发的最大痛点会话状态与工具调用的耦合讲 Hermes 之前我想先聊聊 Agent 开发中大家普遍头疼的问题。如果你只是单纯调用大模型 API 做单轮问答那事情很简单一个 HTTP 请求就搞定了。但 Agent 不一样它意味着模型需要能使用工具、需要能记住上下文、需要能根据中间结果调整下一步的行动。自己从零写的话会遇到几个绕不开的问题多轮会话怎么维护是自己在 Redis 里存消息列表还是每次全量拼接历史工具调用怎么声明和验证模型返回的参数怎么校验错误参数怎么处理模型切换怎么兼容不同提供商的消息格式不一样抽象层怎么设计流式输出怎么处理前端需要打字机效果后端怎么把事件推送出去每一个问题都不算难但它们组合在一起工程量就不小了。更麻烦的是当你的工具数量变多、调用链变长调试的复杂度是线性上升的。Hermes 的解法是把这些共性问题内聚成一个抽象层开发者只需要定义好 Agent 的能力工具、配置好模型参数剩下的会话管理和调用循环都由库来处理。这样你的业务代码就可以专注于做什么而不是怎么做。2.2 Hermes 的架构思想和关键抽象我看了一下 Hermes 的源码结构它的设计有几个关键抽象我分别说一下消息协议层。它内部统一了一套消息格式不管是对话消息、工具调用消息还是结果消息都转成标准的结构。这个抽象的好处是你在切换底层模型的时候业务代码不需要跟着改。比如我今天用 deepseek 的模型做验证明天想换 OpenAI 兼容接口的模型只需要改配置消息组装逻辑是通用的。会话管理模块。负责保存和加载历史对话。对于长期运行的 Agent 服务来说这块尤其重要。Hermes 支持会话持久化你可以在服务重启后恢复之前的对话上下文这个我在实际开发里觉得非常有用。工具注册机制。这是 Agent 的灵魂。Hermes 允许你用装饰器或者注册函数的方式把你的 Python 函数暴露为 Agent 可调用的工具并且有参数校验和错误处理机制。我之前见过有些 Agent 框架的工具系统写得很重光学习成本就很高Hermes 这边就比较直白一个函数就是一个工具文档也清楚。模型接入层。通过配置文件指定模型提供商和模型名称。从目前社区的使用情况来看它主流的做法是兼容 OpenAI 格式的 API这也意味着大量国内外的模型服务都能通过这一层接入。2.3 为什么我选择 Hermes 而不是其他框架市面上 Agent 框架不少有重型的编排框架也有轻量的对话库。我当时的挑选标准有三个一是不捆绑特定的运行环境二是不强制特定的应用架构三是文档和社区要有一手资料。Hermes 在这三点上表现都不错。它不要求你把应用跑在某个特定的服务框架里——你可以把它用在 FastAPI、Flask、Django 甚至一个纯命令行脚本中这给了开发很大的自由度。对于我这种喜欢把 Agent 嵌入到已有系统里的人这个特性是刚需。另外Hermes 对模型提供商选择比较开放。我在项目里既用过 deepseek 的推理模型做复杂任务拆解也用过更轻量的模型做简单问答切换基本就是改配置的事不需要动代码逻辑。3. 环境准备与安装部署3.1 Python 环境准备Hermes 是一个 Python 库所以第一步肯定是准备 Python 环境。官方推荐 Python 3.10 及以上版本我自己实测 3.10 到 3.12 都没有什么问题。如果你用的是 Linux 服务器比如 Ubuntu系统自带的 Python 版本可能偏老。这时候我建议用apt装一个新的版本或者直接用conda管理环境。个人推荐用虚拟环境隔离项目依赖防止不同项目之间的包互相冲突。装完 Python 之后顺手建一个虚拟环境python -m venv hermes-demo source hermes-demo/bin/activate这样后面所有依赖都装在这个环境里不会污染系统环境。3.2 安装 Hermes 库安装部分最简单的方式就是 pip 安装。我通常在装的时候把所有需要的依赖一起装齐避免后面缺东少西pip install hermes-agent注意包名是hermes-agent而不是hermes。我第一次就是没注意直接pip install hermes装了一个完全无关的包白白折腾了一阵子。这一点官方文档里其实写了但是很容易看漏我在这里再强调一次。装完之后可以验证一下版本python -c import hermes; print(hermes.__version__)如果输出正常就说明安装成功了。3.3 模型服务配置Hermes 本身不内置大模型它需要对接一个模型服务。目前最常见的方式是配置一个 OpenAI 兼容的 API 端点。以 deepseek 为例只需要设置 base_url 和 api_key。配置方式有两种。一种是写环境变量export HERMES_API_KEY你的API密钥 export HERMES_BASE_URLhttps://api.deepseek.com/v1 export HERMES_MODELdeepseek-chat另一种是在代码里直接指定适合在多个模型之间切换的场景from hermes import AgentConfig config AgentConfig( api_key你的API密钥, base_urlhttps://api.deepseek.com/v1, modeldeepseek-chat )这里多说一句我建议把 API 密钥放在环境变量或者配置文件里不要硬编码在代码里尤其是如果你会把代码提交到仓库里的话密钥泄露是件很麻烦的事。4. 核心实操从零搭建你的第一个 Hermes Agent4.1 基础对话最小化代码示例我先写一个最简单的 Agent 示例不带任何工具调用只做纯对话。这样做的目的是先跑通链路确认连接没有问题再逐步增加复杂度。from hermes import Agent agent Agent( api_key你的API密钥, base_urlhttps://api.deepseek.com/v1, modeldeepseek-chat ) response agent.chat(用一句话介绍一下你自己) print(response)这段代码跑通之后你就可以确认 Hermes 的安装、模型配置、网络连接都是通畅的后续再往里面加工具调用就心里有底了。如果输出正常接下来我们可以做一点小变化——开启流式输出让模型像打字机一样逐字输出。这在 Web 应用里体验更好用户不需要干等。for chunk in agent.stream_chat(给我讲讲 Agent 开发的最佳实践): print(chunk, end, flushTrue)流式模式我的理解是底层用了 SSEServer-Sent Events每收到一个数据块就回调一次。如果你要做 Web 应用可以在回调里把数据块通过 WebSocket 推给前端。4.2 多轮会话与上下文管理Agent 真正强大的是能记住上下文进行多轮对话。Hermes 的 Agent 对象内部维护了对话历史你连续调用chat()方法时它会自动把历史带进去。agent.chat(我叫小明是一名后端工程师) agent.chat(你还记得我的名字和职业吗)不出意外的话第二轮的回复能准确说出名字和职业。这背后的逻辑是 Hermes 会在内部把历史消息拼装成一个消息列表每次请求都把完整的历史发送给模型。不过这里就有一个常见的坑上下文长度消耗很快。如果你的 Agent 要做长流程任务对话轮次很多token 消耗会快速增长而且模型有上下文窗口限制达到上限之后就会报错。我实际项目里的做法是维护一个上下文管理策略当历史消息达到一定条数时只保留最近 N 轮消息或者用模型对之前的对话做摘要压缩。Hermes 提供了会话历史的清理接口你可以手动控制agent.clear_history()分段保存历史的话可以用它内置的会话持久化功能session_id agent.create_session() agent.chat(你好, session_idsession_id) # 在另一个地方恢复会话 agent.resume_session(session_id) agent.chat(继续说下去)这个功能在做客服系统、个人助手类的应用时很有用。用户在页面上一刷新后端就能通过 session_id 找回之前的上下文体验会连贯很多。4.3 工具调用让 Agent 真正干活纯聊天不是 Agent 的核心价值能调用工具才是。Hermes 的工具注册机制是我最喜欢的部分我们可以将一个普通的 Python 函数注册为 Agent 可用的工具。先看一个最简单的例子——让 Agent 能查询当前时间from datetime import datetime from hermes import tool tool def get_current_time() - str: 获取当前日期和时间 return datetime.now().strftime(%Y-%m-%d %H:%M:%S) agent.register_tool(get_current_time) response agent.chat(现在几点钟了) print(response)当用户问现在几点时Hermes 会分析出需要调用get_current_time这个工具触发你的函数执行拿到返回值之后再让模型组织语言回复给用户。整个过程你不需要手动判断用户的意图模型自己会决定何时调用工具。工具函数支持参数传递。比如做一个简单的计算器工具tool def calculator(expression: str) - float: 计算一个数学表达式的结果 return eval(expression) agent.register_tool(calculator) response agent.chat(请计算 (23 * 45) 78 的结果) print(response)注意看我在函数定义里写了类型注解和 docstringHermes 会利用这些信息告诉模型这个工具是做什么的、需要什么样的参数。所以工具函数的 docstring 一定要写清楚这直接影响模型调用工具的准确率。Hermes 还支持参数校验。如果模型调用工具时传的参数不符合预期比如缺参数或者类型不对库会自动捕获错误并反馈给模型让模型调整参数重新调用。这个问题我后面会在面试者高频踩坑部分详细讲。4.4 一个综合实战嵌入 FastAPI 服务的完整示例下面看一个更接近生产的例子。假设我们要做一个 AI 客服接口它能根据用户输入调用工具查询订单状态然后返回正常的话术。from fastapi import FastAPI, HTTPException from pydantic import BaseModel from hermes import Agent, tool import uvicorn app FastAPI() agent Agent( api_key你的API密钥, base_urlhttps://api.deepseek.com/v1, modeldeepseek-chat ) order_db { 1001: {status: 已发货, eta: 3天后送达}, 1002: {status: 待支付, eta: 请尽快完成支付}, } tool def query_order(order_id: str) - str: 根据订单号查询订单状态和预计送达时间 if order_id in order_db: order order_db[order_id] return f订单状态: {order[status]}, 预计:{order[eta]} return 未找到该订单 agent.register_tool(query_order) class ChatRequest(BaseModel): message: str app.post(/chat) async def chat(request: ChatRequest): try: response agent.chat(request.message) return {reply: response} except Exception as e: raise HTTPException(status_code500, detailfAgent 调用失败: {str(e)}) if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)这个接口上线之后的效果是用户发一句我的订单 1001 什么时候到Agent 会先识别出需要查询订单工具然后调用query_order拿到订单信息再组织成自然的回复返回给用户。整个链路对用户来说是无感的他不需要知道背后有工具调用这回事。我在实际项目中遇到过一个性能层面的问题值得提醒每次请求都重新创建 Agent 对象会使调用变慢因为 Agent 初始化有配置加载和校验的过程。在 FastAPI 这样的 Web 框架里应该把 Agent 对象设为全局单例上面的示例就是这种写法。如果你需要多租户场景不同用户不同模型可以用类似连接池的机制预创建多个 Agent 实例按需分发。4.5 流式输出到前端WebSocket 集成示例工具调用和流式输出都讲了我再加一个比较实用的组合在 WebSocket 里做流式输出。用户在网页那边有一个聊天气泡模型回复一个字一个地蹦出来这个体验需要将 Hermes 的stream_chat和 WebSocket 结合起来。from fastapi import WebSocket from hermes import Agent agent Agent(...) app.websocket(/ws/chat) async def websocket_chat(websocket: WebSocket): await websocket.accept() while True: user_msg await websocket.receive_text() # 将用户的每一条消息交给 Agent实时把生成片段推回前端 for chunk in agent.stream_chat(user_msg): await websocket.send_text(chunk)实际落地的时候几个点要注意模块需要支持多用户并发连接每个 WebSocket 连接要绑定一个独立的会话 ID避免多个用户共享上下文。Hermes 的会话机制支持这一点每个连接进来时创建一个 session_id后面的对话都挂在那个 session_id 下。如果是本地测试可以在一个终端起 FastAPI 服务另一个终端用 Python 的websockets库模拟客户端连入测试。5. 深入机制Hermes 底层的 Agent 循环原理5.1 Agent 的思考-行动-观察循环用熟了 Hermes 之后我建议你也了解一下它底层的 Agent 循环机制这样出了问题你能快速定位是哪个环节的锅。Agent 的一次完整调用在底层会经历一个循环大致流程是这样的接收用户输入把用户消息加入会话历史。模型推理把完整上下文包括工具定义发给模型模型输出两种可能之一直接生成回复或者请求调用某个工具。工具执行如果模型决定调用工具Hermes 会解析出工具名和参数找到注册的函数并执行。反馈给模型把工具的执行结果作为一条新消息返回给模型。重复模型根据工具结果继续推理可能再调用下一个工具也可能给出最终回复。这个循环跟 OpenAI 的函数调用机制是兼容的。所以只要模型接口兼容 OpenAI 的 tool 调用协议Hermes 都能驱动它完成思考-行动-观察的闭环。循环的次数需要有个上限防止 Agent 在工具调用中死循环。Hermes 提供了一个max_iterations参数我一般设置成 5 到 8 次。超过上限之后Agent 会停止工具调用并返回当前信息避免无限消耗 token。5.2 工具如何被模型看见有些朋友可能会好奇Hermes 是怎么把 Python 函数告诉模型的。其实原理并不复杂当你用tool注册一个函数时Hermes 会读取函数的签名、类型注解和 docstring生成一个 JSON Schema 描述然后把这个描述塞到模型请求的tools参数里。比如前面那个get_current_time函数生成的 Schema 大致长这样{ type: function, function: { name: get_current_time, description: 获取当前日期和时间, parameters: { type: object, properties: {}, required: [] } } }模型看到这个描述后在需要知道时间的时候就会返回一个函数调用请求告诉 Hermes我要调用get_current_time。然后 Hermes 负责执行这个函数把结果再传给模型。理解了这一点你就会明白为什么工具函数的 docstring 那么重要——它就是模型理解你的工具的窗口。docstring 写得越清楚模型判断什么时候该用的准确率就越高。常见的反面教材是 docstring 太模糊比如写处理数据模型根本不知道你处理的是哪种数据、要什么参数。5.3 错误恢复机制工具调用一个很常见的场景是模型传了一个错误的参数。比如你有一个函数要求参数是字符串类型但模型传了数字。Hermes 的处理机制是捕获异常把错误信息作为工具结果反馈给模型模型看到错误后往往能修正参数重新调用。这相当于多了一层容错。我在生产环境里遇到过模型把订单号传错的情况Hermes 自动把 Order not found 的结果返回给模型模型马上意识到了错误重新查了一次就成功了。整个过程没有报错崩溃用户体验上看不到任何异常。如果你希望某些错误不告诉模型可以再自行包装一下函数逻辑在内部判断是否返回友好的失败信息。这种模式在支付类业务里尤其重要——不要把底层异常直接暴露给模型。6. 多模型适配与配置技巧6.1 对接不同模型服务商Agent 项目在原型阶段你可能用的是一个模型到生产阶段可能换另一个或者不同业务场景用不同模型。Hermes 在配置层面支持快速切换。以当前的生态来看OpenAI 兼容格式几乎成了事实标准。Hermes 的 base_url 参数让你可以用任何兼容 OpenAI API 的服务。deepseek 的接口可以直接填其他国内厂商只要声明了 OpenAI 兼容接口一般都可以无缝接入。我在一个项目里的实际配置长这样的from hermes import Agent # 简单问答场景用轻量模型 light_agent Agent( api_keyos.environ[DEEPSEEK_API_KEY], base_urlhttps://api.deepseek.com/v1, modeldeepseek-chat, temperature0.7 ) # 复杂推理场景用更强模型 reasoning_agent Agent( api_keyos.environ[DEEPSEEK_API_KEY], base_urlhttps://api.deepseek.com/v1, modeldeepseek-reasoner, temperature0.3, max_tokens2048 )两个 Agent 实例互不干扰业务层可以根据任务难度路由到不同的实例。这个模式我强烈推荐——不要试图用一个 Agent 处理所有任务不同任务的性能要求、成本要求不一样拆开用更划算。6.2 参数调优的实践心得用 Hermes 一段时间后我总结出几个在参数配置上的经验这里分享给大家温度参数。temperature 控制输出的随机性。做创意写作可以开到 0.8 以上做信息抽取、代码生成这种精确任务建议调到 0.1-0.3。Hermes 的 AgentConfig 里可以直接设置需要注意的是有些模型比如 deepseek-reasoner自身可能对 temperature 有限制你在传参的时候要多留意模型原文文档。最大 token 数。max_tokens 控制单次回复的最大长度不是上下文总长度。如果你的 Agent 可能生成很长的回复比如报告类内容就调大如果是短对话调小可以降低延迟。迭代次数上限。max_iterations 是 Agent 单轮对话里最多执行工具调用的次数。如果 Agent 的流程涉及多步工具调用比如先查库存、再算价格、再下订单这个值要调大一点否则 Agent 会在中途停止。我踩过的一个坑是某个 Agent 任务需要 3 次工具调用但 max_iterations 默认只有 3结果每次都在最后一次调用前停止。后来我改成 6 就好了。6.3 CLI 工具的嵌入实践除了 Web 服务把 Agent 嵌进命令行工具也是 Hermes 的一个典型用法。我写过一个运维排查脚本把 Hermes 作为子命令嵌入到主 CLI 里import argparse from hermes import Agent def run_agent_query(query: str): agent Agent(...) response agent.chat(query) print(response) parser argparse.ArgumentParser(descriptionAI 助手 CLI) subparsers parser.add_subparsers(destcommand) ask_parser subparsers.add_parser(ask) ask_parser.add_argument(query, typestr, help输入你的问题) args parser.parse_args() if args.command ask: run_agent_query(args.query)这样在终端里执行python main.py ask 帮我分析一下今天日志里的报错上面的 Agent 就会开始工作。对于不擅长 Web 开发的同学来说CLI 是快速体验 Agent 能力的好方式。7. 常见问题与排查技巧7.1 连接超时与重试机制我在生产和本地测试中都遇到过 API 调用超时的情况。原因多数是网络波动、模型服务端负载过高或者你的请求体太大比如传入了超长上下文。Hermes 允许设置超时时间我建议显式配置而不是用默认值config AgentConfig( api_key..., timeout30, max_retries3 )如果遇到超时库会自动重试。但注意重试可能导致重复消费 token尤其是请求已经在服务端执行但响应没有到达的情况。我在幂等性要求高的场景里会关闭自动重试自己做补偿逻辑。排查超时的经验先去base_url/health看服务端是否健康再看请求大小是否超过了模型的上下文窗口最后看是偶发还是必现。偶发通常可以重试解决必现大概率是配置或参数的问题。7.2 工具调用失败参数校验与错误处理工具调用失败是 Agent 开发中最容易碰到的问题。我归纳下来有这么几种典型情况模型传的参数缺少必填字段参数类型不对传了字符串但函数要求整数工具函数内部抛了未捕获的异常工具业务逻辑返回了错误但没反馈给模型。Hermes 本身有参数校验机制部分错误它可以自动修复方法就是用 try-except 捕获后重新把错误发回模型推理。但如果你的工具函数内部逻辑抛了异常Hermes 默认可能不会把具体异常内容完整传给模型你需要自己在函数里处理。我的建议是在工具函数内部做防御性编程tool def query_order(order_id: str) - str: 根据订单号查询订单状态 if not order_id: return 订单号不能为空请提供订单号 if not order_id.isdigit(): return 订单号格式错误订单号应为数字 order order_db.get(order_id) if not order: return 未找到该订单请检查订单号 return f订单状态: {order[status]}这样无论模型传什么参数进来你的函数都返回一个可读的文本结果Hermes 会把结果反馈给模型模型据此修正。这是一个非常重要的工程实践不要让异常冒泡到 Agent 循环外面尽量让工具返回可解释的结果。7.3 如何查看 Agent 的调试日志Agent 循环内部做了什么对新手来说是黑盒。Hermes 提供了日志功能你可以在初始化时开启调试模式import logging logging.basicConfig(levellogging.DEBUG)这样就能在控制台看到 Agent 每一步的详细信息发送了什么请求、模型返回了什么、调用了哪个工具、工具返回了什么、最终回复是什么。这是排查问题的利器。我自己调试时的习惯是先开 DEBUG 日志看一遍完整的交互轨迹确认 Agent 决策逻辑是否合理然后再针对模型输出中断、工具调用错误这些具体问题做定向修复。7.4 常见问题速查表现象可能原因解决办法安装时提示找不到包包名写错写了 hermes 而不是 hermes-agent用pip install hermes-agent首次调用报连接错误API Key 或 base_url 配置错误检查环境变量和 AgentConfig 参数上下文很长时报错超出模型上下文窗口减少历史轮次开启摘要工具调用不生效模型没有返回 tool_calls检查工具 docstring 是否清晰模型是否支持 tool 调用回复内容被截断max_tokens 设置太小调大 max_tokens模型回复格式不对temperature 过高导致输出不稳定降低 temperature 到 0.2-0.48. 进阶技巧与扩展方向8.1 多 Agent 协作模式Hermes 单个 Agent 能解决的问题有限但你可以用多个 Agent 协作构建更复杂的系统。最简单的模式是主 Agent 辅助 Agent主 Agent 负责理解用户意图然后将子任务分发给不同的辅助 Agent 处理。我在一个文档问答项目里就用过三个 Agent一个负责检索调用搜索引擎 API 或本地数据库一个负责总结把检索结果整理成结构化答案一个负责写作把答案润色成自然语言的长文。三者通过消息传递串联Hermes 可以分别实例化只需要保证消息格式能互通。这个模式的扩展性很好后面的能力增强只需要增加新的 Agent不需要改动原来的 Agent。8.2 持久化存储和会话恢复的价值前面提到了 session 相关的能力我再展开说说生产环境里的经验。Agent 应用一旦长期运行会话数据会越来越大。Hermes 支持把会话历史存储到 Redis 或数据库这样服务重启后可以恢复。我在一个客服项目里是这么用的用户进入对话时分配 session_id每次聊天后把 session 状态保存到 Redis。用户刷新页面回来后从 Redis 里取出 session每个用户独享一个上下文。这比把所有用户的历史都堆在内存里靠谱得多也不怕服务重启丢上下文。具体调用可以通过load_session和save_session这类接口实现。如果 Hermes 内置的存储后端不满足你的需求你也可以自己实现一个存储类本质就是把会话消息序列化后存下来。8.3 与 docker 配合的部署方案如果你想把 Hermes 应用容器化部署Dockerfile 写起来不复杂。我整理了一个最小的参考FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . ENV HERMES_API_KEY ENV HERMES_BASE_URL ENV HERMES_MODEL CMD [python, main.py]部署的时候用docker run加上环境变量即可docker build -t hermes-app . docker run -d --name hermes-app \ -e HERMES_API_KEY你的API密钥 \ -e HERMES_BASE_URLhttps://api.deepseek.com/v1 \ -e HERMES_MODELdeepseek-chat \ -p 8000:8000 hermes-app容器化处理的优势是环境统一、部署一致。生产环境里还可以再接一个反向代理层面做负载均衡和限流这些都不是 Hermes 本身的事情但你可以在架构层面把它当作一个普通的 Python 服务来对待。我个人在实际操作里最满意 Hermes 的地方是它的模块化程度——我可以在一个系统里同时跑多个 Agent 实例有的做路由有的做执行有的做总结它们之间相互独立又通过消息协作。相比那些把一切功能都捆绑在一起的框架这种自由度正是我需要的。希望你读完这篇回顾之后也能在自己的项目里找到合适的位置把 Agent 的能力真正嵌进你的应用里。