langchain内置中间件：

Middleware 中间件	Description 描述
Summarization 摘要	Automatically summarize conversation history when approaching token limits. 接近token限制时自动总结对话记录。
Human-in-the-loop 人机参与	Pause execution for human approval of tool calls. 暂停执行以供人工批准工具调用。
Model call limit 模型呼叫限制	Limit the number of model calls to prevent excessive costs. 限制模型调用次数，以防止过高成本。
Tool call limit 工具调用限制	Control tool execution by limiting call counts. 通过限制呼叫次数来控制工具执行。
Model fallback 模型的备选	Automatically fallback to alternative models when primary fails. 当主模式失败时，会自动回退到其他模式。
PII detection PII 检测	Detect and handle Personally Identifiable Information (PII). 检测并处理个人身份信息（PII）。
To-do list 待办事项列表	Equip agents with task planning and tracking capabilities. 为客服人员配备任务规划和跟踪能力。
LLM tool selector LLM 工具选择器	Use an LLM to select relevant tools before calling main model. 在调用主模型之前，先用 LLM 选择相关工具。
Tool retry 工具重试	Automatically retry failed tool calls with exponential backoff. 用指数回撤自动重试失败的工具调用。
Model retry 模型重试	Automatically retry failed model calls with exponential backoff. 自动用指数退回方式重试失败的模型调用。
LLM tool emulator LLM 工具仿真器	Emulate tool execution using an LLM for testing purposes. 用 LLM 模拟工具执行以进行测试。
Context editing 上下文编辑	Manage conversation context by trimming or clearing tool uses. 通过修剪或清理工具使用来管理对话上下文。
Shell tool 壳体工具	Expose a persistent shell session to agents for command execution. 向代理开放一个持久的壳会话以执行命令。
File search 文件搜索	Provide Glob and Grep search tools over filesystem files. 在文件系统文件上提供 Glob 和 Grep 搜索工具。
Filesystem 文件系统	Provide agents with a filesystem for storing context and long-term memories. 为代理提供存储上下文和长期记忆的文件系统。
Subagent 副代理人	Add the ability to spawn subagents. 增加生成子代理人的能力。

内置中间件的简单讲解和介绍：

LangChain 等 AI Agent 框架提供的内置中间件，本质上是为了让智能体更可靠、更安全、更省钱而设计的“通用增强插件”。它们将一些与核心业务逻辑无关的“横切关注点”（如日志、权限、重试等）从 Agent 的核心执行循环中解耦出来。

以下是这些内置中间件的逐条通俗讲解：

1. Summarization（摘要中间件）

• 核心作用：自动压缩对话历史，防止上下文超限。
• 通俗讲解：当对话轮数过多，即将超出大模型的 Token 记忆上限时，它会自动把旧的聊天记录浓缩成一段简短的摘要，同时保留最近几条最新的消息。这就像给 Agent 做了一个“记忆压缩”，既省了 Token 费用，又保证了 Agent 不会“失忆”。

2. Human-in-the-loop（人机参与中间件）

• 核心作用：在敏感操作前暂停执行，等待人工审批。
• 通俗讲解：这是 Agent 的安全阀。当 Agent 准备执行高风险操作（如删除数据库、金融转账、发邮件）时，它会立刻“挂机”暂停，必须等人类点击“批准”或“拒绝”后，它才能继续往下干活。

3. Model call limit（模型呼叫限制中间件）

• 核心作用：限制大模型的调用次数，防止成本失控。
• 通俗讲解：给 Agent 设定一个“预算”。比如规定单次任务最多只能问大模型 10 次。如果 Agent 陷入死循环，不停地向大模型提问，到了次数限制就会被强制掐断，避免 API 账单爆炸。

4. Tool call limit（工具调用限制中间件）

• 核心作用：限制工具的执行次数。
• 通俗讲解：防止 Agent 高频调用外部付费 API（如天气接口、股票接口）。通过限制调用次数，避免因为 Agent 的疯狂请求导致第三方 API 成本失控。

5. Model fallback（模型备选/回退中间件）

• 核心作用：主模型故障时，自动切换到备用模型。
• 通俗讲解：相当于给 Agent 准备了“备胎”。如果主模型（如 GPT-4）宕机或响应超时，中间件会自动无缝切换到备用模型（如 GPT-3.5 或 Claude），保证服务不中断。

6. PII detection（PII 检测中间件）

• 核心作用：检测并处理个人身份信息（PII）。
• 通俗讲解：隐私保镖。在将数据发给大模型或记录日志前，自动识别并打码处理手机号、身份证、银行卡等敏感信息，确保符合数据合规要求。

7. To-do list（待办事项列表中间件）

• 核心作用：为 Agent 装备任务规划和追踪能力。
• 通俗讲解：给 Agent 发一个“记事本”。在处理多步骤的复杂任务时，Agent 可以把大任务拆解成一个个小待办事项（To-do list），做完一项勾一项，防止遗漏关键步骤。

8. LLM tool selector（LLM 工具选择器中间件）

• 核心作用：在调用主模型前，先用小模型筛选相关工具。
• 通俗讲解：当注册给 Agent 的工具非常多时，每次把所有工具介绍都发给大模型会消耗大量 Token。这个中间件会先用一个便宜的小模型快速挑出几个“可能用到的工具”，再交给主模型，既省 Token 又提高了精度。

9. Tool retry（工具重试中间件）

• 核心作用：用指数回撤策略自动重试失败的工具调用。
• 通俗讲解：外部 API 偶尔会因为网络抖动报错。这个中间件能让 Agent 在遇到报错时自动多试几次（比如隔 1 秒、2 秒、4 秒再试），提高获取数据的成功率。

10. Model retry（模型重试中间件）

• 核心作用：自动重试失败的大模型调用。
• 通俗讲解：与工具重试类似，当大模型服务商出现临时限流或网络波动时，自动帮 Agent 重新发起请求，确保任务顺利完成。

11. LLM tool emulator（LLM 工具仿真器中间件）

• 核心作用：用 LLM 模拟工具执行以进行测试。
• 通俗讲解：在开发测试阶段，真实的工具（如数据库）可能还没准备好。这个中间件可以让大模型“假装”工具已经执行并返回一个模拟结果，方便开发者提前调试 Agent 的逻辑。

12. Context editing（上下文编辑中间件）

• 核心作用：动态修剪或清理对话上下文。
• 通俗讲解：在发给大模型之前，对历史消息进行“大扫除”。比如自动删除过期的、无效的工具调用结果，只保留最新的有效信息，引导 Agent 更专注地处理当前任务。

13. Shell tool（壳体工具中间件）

• 核心作用：向代理开放一个持久的 Shell 会话以执行命令。
• 通俗讲解：给 Agent 一个可以直接敲代码的“终端窗口”。Agent 可以在里面执行系统命令，并且能保持会话状态（比如先进入某个文件夹，再执行后续操作）。

14. File search（文件搜索中间件）

• 核心作用：提供文件系统的全局（Glob）和文本（Grep）搜索工具。
• 通俗讲解：赋予 Agent 在电脑文件夹里“找文件”和“搜内容”的能力，让它能自主检索本地或服务器上的特定文件。

15. Filesystem（文件系统中间件）

• 核心作用：为代理提供文件系统，用于存储上下文和长期记忆。
• 通俗讲解：给 Agent 配一个“专属硬盘”。Agent 可以把重要的数据、长期的记忆写进文件里保存起来，下次需要时再读取，突破了对话窗口的记忆限制。

16. Subagent（副代理人/子代理中间件）

• 核心作用：增加生成子代理人的能力。
• 通俗讲解：允许主 Agent 在遇到复杂问题时，临时“召唤”或“外包”给一个专门处理特定任务的子 Agent（比如专门写代码的子 Agent），处理完后再把结果汇报给主 Agent

1.3 自定义中间件

维度	节点式 (Node-style)	包装式 (Wrap-style)	便利装饰器 (Convenience)
控制权	无（只能看和记）	强（可拦截、重试、修改）	中等（专注单一功能）
执行逻辑	线性顺序执行	嵌套包裹（洋葱模型）	特定场景的快捷调用
数据焦点	全局状态 (AgentState)	单次请求 (ModelRequest)	特定参数（如 Prompt）
典型用途	日志、审计、状态同步	缓存、重试、降级、熔断	动态提示词生成

在 LangChain 和 LangGraph 的 Agent 框架中，中间件（Middleware）就像是在 Agent 核心执行循环中设置的一系列“检查站”或“拦截点”。

为了让你更清晰地理解，我们可以将 Agent 的一次完整任务执行看作一个**“思考-行动-观察”的循环**。以下是各个触发时机的详细解析，以及在这些时机点，大模型（LLM）和 Agent 分别处于什么状态、干了什么：

1. before_agent（智能体启动前）

• 触发时机：Agent 被调用（invoke），但尚未执行任何内部逻辑之前。在整个运行周期中仅触发一次。
• 大模型（LLM）的状态：完全未参与。此时大模型还没有收到任何信息。
• Agent 的状态：正在做“热身准备”。它刚刚接收到用户的初始输入，正在初始化全局状态。
• 核心作用：初始化请求级上下文（如生成唯一的 Request ID）、加载用户特定的配置（如从数据库读取用户偏好）、重置临时计数器。

2. before_model（模型调用前）

• 触发时机：在 Agent 的每一次推理循环中，即将向大模型发送网络请求之前。由于 Agent 是循环执行的（思考-行动-观察），此钩子在一次任务中可能会被触发多次。
• 大模型（LLM）的状态：准备接收指令。它还没有开始计算，正在等待 Agent 将当前的对话历史（Messages）和提示词（Prompt）发送给它。
• Agent 的状态：已经完成了上一轮的观察，或者刚刚启动。它正在整理当前的对话历史，准备把这些信息“喂”给大模型以获取下一步的决策。
• 核心作用：动态修改 Prompt（如注入当前时间）、检查 Token 预算、对长对话历史进行摘要或修剪、实施前置安全过滤（如拦截恶意指令）。

3. modify_model_request（修改模型请求）

• 触发时机：在模型调用前立即执行，但作用域限定在特定请求范围内。
• 大模型（LLM）的状态：等待参数微调。
• Agent 的状态：已经构建好了发送给大模型的基础请求，但允许中间件对这次“单次请求”进行微调。
• 核心作用：修改传递给大语言模型的工具列表、调整模型参数（如温度、最大 token 数）、动态调整输出格式。关键点：这些修改不会改变 Agent 的永久状态，只影响当前这一次请求。

4. after_model（模型返回后）

• 触发时机：在每一次大模型返回响应之后触发，但在 Agent 执行任何工具调用之前。
• 大模型（LLM）的状态：刚刚完成推理。它已经吐出了原始的文本响应（Generation），可能包含下一步要调用的工具名称和参数，也可能包含直接回复给用户的话。
• Agent 的状态：拿到了大模型的“思考结果”，但还没有去执行。它正在等待确认：这个结果安全吗？需要调用工具吗？
• 核心作用：审查模型输出（如检测幻觉、有害内容或违禁词）、记录推理耗时、计算 Token 消耗。如果发现高风险操作，可以在此处触发人机交互中断（等待人工批准）。

5. before_tool（工具调用前）

• 触发时机：当 Agent 解析出大模型的回复，确认需要调用外部工具（如执行 bash 命令、读写文件、查询数据库）时。
• 大模型（LLM）的状态：处于休息状态。它在等待工具返回执行结果，以便进行下一轮的思考。
• Agent 的状态：准备充当“执行者”。它已经拿到了工具名和参数，正准备向操作系统或第三方 API 发起真实请求。
• 核心作用：安全沙箱拦截（防止执行 rm -rf 等危险命令）、权限控制、防止密钥泄露。

6. after_tool（工具返回后）

• 触发时机：外部工具执行完毕，结果即将发回给大模型进行下一轮思考之前。
• 大模型（LLM）的状态：准备接收反馈。它即将看到工具执行的结果（比如数据库查询出的数据，或者命令执行的报错信息）。
• Agent 的状态：刚刚完成了一次“行动”，拿到了原始的执行结果，正准备把这个结果作为“观察（Observation）”反馈给大模型。
• 核心作用：结果脱敏（将执行结果中的敏感 IP、密码替换为 [REDACTED]）、格式化输出，确保传给大模型的数据是干净且安全的。

7. after_agent（智能体结束后）

• 触发时机：Agent 完成了所有的思考、行动和观察循环，准备将最终结果返回给用户时。在整个运行周期中仅触发一次。
• 大模型（LLM）的状态：任务彻底结束。
• Agent 的状态：已经得出了最终结论，正在做“收尾工作”。
• 核心作用：清理资源、生成最终审计报告、格式化输出结果、将完整的执行轨迹（Trace）持久化到数据库以便后续复盘。

---

 总结：执行流向图

为了方便记忆，你可以将这个过程想象成一次**“快递运输”**：

1. before_agent：快递员接单，打印运单（初始化状态）。
2. before_model：快递员把包裹（Prompt）装上车，准备出发去转运中心（LLM）。
3. modify_model_request：出发前最后检查，换个更合适的包装盒（微调单次请求参数）。
4. after_model：包裹到达转运中心（LLM），分拣员给出了下一步指令（模型返回结果），但在装车前检查包裹是否违禁（安全审查）。
5. before_tool：准备把包裹送到具体地址（调用工具），检查地址是否合法（工具权限拦截）。
6. after_tool：包裹送达并拿到了签收单（工具返回结果），把签收单上的客户隐私信息涂黑（结果脱敏），准备带回给转运中心。
7. after_agent：所有流程走完，快递员将最终签收结果录入系统并汇报给客户（持久化状态，返回最终结果）。

1. 你想做“宏观”操作（比如：删掉旧消息、注入当前时间、拦截违禁词），用 before_model。
2. 如果你想做“微观”微调（比如：仅仅针对这一次提问，临时把模型的温度 temperature 调低，或者临时隐藏掉某个工具），那么应该用 modify_model_request。
3. before_model 可以操作提示词，但它操作的是“全局的消息列表（Agent State）”。

短期记忆（Short-term Memory）：只管“现在这个聊天里说了什么” 别名：会话记忆（Session Memory）、工作记忆（Working Memory）。 作用范围：单线程 / 单会话内。它只服务于当前这一轮对话。 核心内容：当前会话的对话历史（Messages）、当前任务的执行状态、刚刚查询到的临时数据。 技术载体：通常由 AgentState 中的 messages 键承载，并通过 Checkpointer（如 InMemorySaver）进行管理。 核心限制：受限于大模型的上下文窗口（Token 限制）。如果对话太长，必须通过修剪、摘要等方式进行压缩。 通俗理解：就像你“当前的草稿纸”。你正在做这道数学题，草稿纸上写满了当前的计算步骤。一旦这道题做完了（会话结束），草稿纸就会被清空或扔掉。

长期记忆（Long-term Memory）：管“这个用户之前所有聊天里的关键信息” 别名：持久化记忆（Persistent Memory）。 作用范围：跨会话、跨线程、用户级或全局级。 核心内容：用户的长期偏好（如喜欢什么风格）、用户画像（如职业、年龄）、历史任务总结出的经验或知识库。 技术载体：通常由 Store（如 LangGraph Store）或向量数据库（Vector DB）承载。数据以 JSON 文档或向量形式按命名空间（Namespace）组织。 核心限制：没有 Token 窗口限制，但为了避免信息冗余，通常需要通过语义检索（搜索）来提取最相关的记忆，而不是全量加载。 通俗理解：就像你的“个人档案库”或“笔记本”。无论你在什么时候来找我，我都可以随时翻阅这个档案，知道“你最喜欢吃西红柿炒鸡蛋”或者“你是一名程序员”。

从工具中写入长期记忆

from dataclasses import dataclass
from typing_extensions import TypedDict

from langchain.agents import create_agent
from langchain.tools import tool, ToolRuntime
from langgraph.store.memory import InMemoryStore
from langchain_openai import ChatOpenAI

# 1 连接模型
model = ChatOpenAI(
    model="qwen-plus",
    api_key="sk-6459007b813946289da12857950c955b",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

# 2 创建 store对象
store = InMemoryStore()

# 3 定义一个上下文对象
@dataclass
class Context:
    user_id: str

# TypedDict 定义了供 LLM 使用的用户信息结构
class UserInfo(TypedDict):
    name: str

# 4 定义一个工具--》取出用户传入的用户信息---》存储到长期记忆中
# 允许智能体更新用户信息的工具（适用于聊天应用）
@tool
def save_user_info(user_info: UserInfo, runtime: ToolRuntime[Context]) -> str:
    """Save user info."""
    # 访问 store - 与提供给 `create_agent` 的 store 相同
    store = runtime.store # 运行时中拿长期记忆   还能拿到短期记忆，上下文。。。
    user_id = runtime.context.user_id #  运行时 拿 上下文
    # 在 store 中存储数据 (namespace, key, data)
    store.put(("users",), user_id, user_info) # 向长期记忆中存：namespace，key，具体内容
    return "Successfully saved user info."

# 5 创建智能体
agent = create_agent(
    model=model,
    tools=[save_user_info], # 工具
    store=store,            # 这里传入了store对象，后续能从运行时runtime中取出store
    context_schema=Context  # 传入上下文对象的类型
)

# 6 运行智能体
agent.invoke(
    {"messages": [{"role": "user", "content": "My name is lqz"}]},
    # 在 context 中传入 user_id 以识别正在更新谁的信息
    context=Context(user_id="user_123")
)
# 7 调用model，会触发工具执行--》就会把 user_123:{user_name:lqz}-->存到store长期记忆中


# 后续我们从任意位置，都能取出长期记忆中存的值
# 您可以直接访问 store 来获取该值
print(store.get(("users",), "user_123").value)

从工具中取出长期记忆

from dataclasses import dataclass
from langchain.agents import create_agent
from langchain.tools import tool, ToolRuntime
from langgraph.store.memory import InMemoryStore
from langchain_openai import ChatOpenAI
# 1 连接模型
model = ChatOpenAI(
    model="qwen-plus",
    api_key="sk-6459007b813946289da12857950c955b",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

# 2 定义 Context
@dataclass
class Context:
    user_id: str

# 3 实例化得到长期记忆对象
store = InMemoryStore()



# # python 基础知识
# # 不可变数据类型，可以作为字典的key
# a=11
# b='lqz'
# c=(1,)
# # 可变数据类型，不能作为字典的key
# l=[1,] # 列表
# d={'name':'lqz'}  # 字典
# s={1,}

# 4 直接写入 ：使用 put 方法向 store 写入示例数据
store.put(     # 元组，字符串，数字 是不可变类型
    ("users",),  # 用于将相关数据分组的命名空间（用于用户数据的 users 命名空间）
    "user_123",  # 命名空间内的 Key（用户 ID 作为 Key）
    {
        "name": "lqz",
        "language": "English",
    }  # 为给定用户存储的数据
)

# 工具要不要传参数，是我们写代码的决定的---》来调用它，是大模型决定的
'''
look up user information--->给了大模型---》结合工具：get_user_info---》不需要解析出参数的
look up user information,user_id is user_123--->给了大模型---》结合工具：get_user_info---》不会，工具不需要参数
look up user information--->给了大模型---》大模型决定调工具：get_user_info--》不传参数，我们不知道拿谁的信息
    -工具中：拿到上下文：runtime.context
    -调用模型时，在上下中传入了 user_id
    -工具中就能拿到 user_id
    -根据 user_id 去长期记忆中取出对于的人名---》返回人名了
'''
@tool
def get_user_info(runtime: ToolRuntime[Context]) -> str:
    """Look up user info."""
    # 访问 store - 与提供给 `create_agent` 的 store 是一个，store中有 put进去的数据
    store = runtime.store
    # 从上下中取出：user_id：user_123
    user_id = runtime.context.user_id
    # 从 store 检索数据 - 返回带有 value 和 metadata 的 StoreValue 对象
    user_info = store.get(("users",), user_id) #
    return str(user_info.value) if user_info else "Unknown user"

agent = create_agent(
    model=model,
    tools=[get_user_info],
    # 将 store 传递给智能体 - 使智能体能够在运行工具时访问 store
    store=store,
    context_schema=Context
)

# 运行智能体
res=agent.invoke(
    {"messages": [{"role": "user", "content": "look up user information"}]},
    context=Context(user_id="user_123")
)
print(res['messages'][-1])

核心功能定位

1. 实现跨会话记忆（长期记忆）

短期记忆（Checkpointer）：仅保存单次对话线程内的上下文（如当前对话的聊天记录），对话结束即清空。

长期记忆（Store）：通过 InMemoryStore 跨多个独立会话持久化关键数据（如用户偏好、历史决策），即使用户关闭页面后重新打开，智能体仍能“记得”重要信息。

关键区别：
Checkpointer 保存的是“这次对话发生了什么”，而 Store 保存的是“需要长期记住什么”。

2. 结构化存储与精准检索

命名空间（Namespace）：
通过元组（如 ("users", "user_123", "preferences")）实现层级化数据组织，避免信息混乱。

LangChain长期记忆中的Namespace本质是数据存储的物理路径标识符，其底层实现是将元组（tuple）结构直接映射为数据库的存储路径，通过这种设计实现数据隔离。

唯一键（Key）：
用 UUID 或业务 ID（如 "user_123"）作为键，精准定位单条记忆，避免数据覆盖。

示例：
存储用户语言偏好时，store.put(("users",), "user_123", {"language": "English"}) 会将其归类到 users 命名空间下，后续可通过相同路径直接读取。

from dataclasses import dataclass

from langchain_core.runnables import RunnableConfig
from langchain.agents import create_agent, AgentStateay
from langchain.tools import tool, ToolRuntime
from langgraph.store.memory import InMemoryStore
from langgraph.runtime import Runtime
from langchain_openai import ChatOpenAI
from langchain.agents.middleware import dynamic_prompt, ModelRequest, before_model, after_model
model = ChatOpenAI(
    model="qwen-plus",
    api_key="sk-6459007b813946289da12857950c955b",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)
@dataclass
class Context:
    user_name: str

### 1 工具中使用
@tool
def fetch_user_name(runtime: ToolRuntime[Context]) -> str:
    """获取用户姓名."""
    user_name = runtime.context.user_name
    return user_name

### 2 在中间件内部 (Inside middleware)
@before_model
def log_before_model(state: AgentState, runtime: Runtime[Context]) -> dict | None:  # [!code highlight]
    print(f"Processing request for user: {runtime.context.user_name}")  # [!code highlight]
    return None
agent = create_agent(
    model=model,
    middleware=[log_before_model],
    tools=[fetch_user_name],
    context_schema=Context
)

res=agent.invoke(
    {"messages": [{"role": "user", "content": "What's my name?"}]},
    context=Context(user_name="lqz")
)
print(res)

运行时：

也就是runtime和troolruntime

1.Runtime（全局流程视角）
代表整个 Agent 工作流的执行环境，生命周期覆盖从 agent.invoke() 开始到结束的全过程

class Runtime[ContextT]:
    context: ContextT          # 自定义上下文（如用户ID）
    store: BaseStore           # 长期记忆存储
    stream_writer: StreamWriter # 流式输出控制
    previous: Any              # 上一个节点的执行结果

• 使用场景：
  中间件（Middleware）（如 @before_model 钩子）中必须使用 Runtime，用于：
  • 全局权限校验（例如检查 runtime.context.user_id 是否有权限）
  • 流程级日志记录（例如记录整个请求的耗时）
  • 跨工具调用的状态协调、

Runtime是代表整个智能体的状态

2 ToolRuntime（工具调用视角）
仅代表当前这一次工具调用的执行环境，生命周期仅限于单个工具函数的执行过程。

class ToolRuntime[ContextT, StateT](Runtime[ContextT]):
    state: StateT              # 当前工作流的完整状态（只读）
    config: RunnableConfig     # 当前调用的配置
    tool_call_id: str          # 本次工具调用的唯一ID
    # 注意：依然包含 Runtime 的所有属性（context/store/stream_writer）

工具函数（@tool） 中必须使用 ToolRuntime，

用于： 安全访问当前工作流状态（例如读取对话历史 runtime.state["messages"]）

关联工具调用ID（用于错误追踪或结果匹配）

避免工具直接修改全局状态（通过提供只读 state 实现隔离）

就是ToolRuntime是代表工具的状态  

agent的调用：

invoke 和 stream 是 LangChain/LangGraph 中调用整个 Agent 的标准入口方法。它们是 Runnable 接口定义的规范调用方式，本质是 Agent 执行流程的“启动开关”。

Agent 作为 Runnable 的实现：
Agent 本身是一个 复合 Runnable（由 Prompt、Model、Tools 等子组件组成），因此必须通过 Runnable 接口定义的方法触发执行。 标准方法：
invoke、stream、batch、ainvoke 等是 Runnable 接口的强制实现方法，所有 Agent 必须提供这些入口。

skills是什么：

 skills--->就是一堆提示词--》提前写好的提示词
     -使用代码大模型写代码---》
         第一次写个金字塔：张三写的
            第二次写个99乘法表：李四写的
            -----代码规范，很混乱----
        -skills预设的提示词，限定代码规范
         第一次写个金字塔：张三写的
            第二次写个99乘法表：张三写的
            -----代码规范统一----