Agno 从入门到精通（二）：工具、知识库与记忆，让 Agent 真正可用

上一篇我们把 Agno 的第一层跑通了：什么是 Agno，为什么它最近在 Agent 框架里热度很高，以及怎样写一个只读项目清点智能体。

如果说第一篇解决的是“Agent 能不能跑起来”，这一篇要解决的是更关键的问题：

Agent 怎样从一个会聊天、会调工具的 demo，
变成一个能查知识、记住上下文、受工具边界约束、并且后续可服务化的系统？

这个问题很朴素，但也很容易被低估。很多 Agent demo 看起来惊艳，是因为只处理一轮对话、一个工具、一个理想问题。真正放进业务系统时，问题马上变得现实：

  • 用户问的问题来自公司知识库，不在模型预训练语料里。
  • 用户会追问“刚才那个方案为什么这么排”，Agent 需要记住会话历史。
  • 用户会让 Agent “顺手保存一个跟进事项”，这就从只读问答变成了写操作。
  • 工具调用一多，就要考虑权限、成本、次数限制和失败回滚。
  • 线上出错以后，团队需要知道到底是模型错、检索错、工具错，还是上下文错。

所以 Agno 第二篇，我不打算继续堆概念，而是围绕四个最实用的基础能力展开：

Tools       让 Agent 做事
Knowledge   让 Agent 查资料
Storage     让 Agent 记住本次会话
Memory      让 Agent 记住用户长期事实

最后我们会实现一个“小型技术支持知识库 Agent”：它能先查本地知识库，再按步骤回答，并且在用户明确要求时调用自定义工具记录跟进事项。

本文基于检索到的 Agno 官方文档、GitHub、PyPI 和 Git 标签快照整理。数据会变化，代码接口也可能随版本演进；具体工程里请以你安装版本的官方文档为准。

1. 先看当前快照：Agno 仍在高速迭代

先补一眼最近状态，避免我们拿着过期印象写系列文章。

截至 2026-08-03 通过 GitHub API 抓取的快照：

项目 信息
主仓 agno-agi/agno
GitHub 描述 Build, run, and manage agent platforms.
许可证 Apache-2.0
star / fork 约 41551 stars / 5725 forks
最近 push 2026-08-03T03:34:06Z
当前 PyPI 版本 agno 2.8.6
PyPI 上传时间 2026-07-30T13:52:18Z
最新 GitHub Release v2.8.6，2026-07-30 发布

和上一篇写作时的 2.8.5 相比，2.8.6 的变化很有代表性。Release notes 里新增了 Smallest AI 文本转语音工具、OpenSearch 向量数据库支持、AgentOS 指标刷新状态接口，也修复了 AgentOS 指标刷新阻塞 worker、工具包装时重复读取 Pydantic 版本造成的热路径开销等问题。

这些更新说明 Agno 的重点并不只是“再接一个模型”或“再加一个小工具”，而是在补三个生产化方向：

  1. 更多工具与外部系统连接。
  2. 更多知识库/向量库选择。
  3. 更强的运行时观测、指标和后台任务能力。

再看官方组织下的 AgentOS 模板仓库，也能看到这个趋势。agentos-railway、agentos-docker、agentos-aws、agentos-gcp、agentos-azure、agentos-fly、agentos-render、agentos-modal、agentos-helm 等仓库在 2026-07-29 附近集中更新，说明 Agno 的设计重心已经明显从 SDK 走向“Agent 平台怎么部署、管理、观测”。

这也是本系列后续的主线：

第一篇：跑通一个 Agent
第二篇：工具 + 知识库 + 会话，让 Agent 有用
第三篇：Storage、Memory、Learning，做长期可改进的 Agent
第四篇：AgentOS，把 Agent 服务化
第五篇：Teams / Workflows，多智能体与流程编排
第六篇：评测、Tracing、权限与上线清单

当然，节奏可以调整。这一篇先把最常用的四块基础能力讲透。

2. Tools：工具不是插件列表，而是 Agent 的行动边界

在 Agno 里，工具可以是官方 Toolkit，也可以是你自己写的 Python 函数。官方 Agent with Tools 示例用的是 HackerNewsTools()，而 Custom Tool for Self-Learning 示例强调了一个很重要的点：任何函数都可以成为工具，但函数名、类型注解和 docstring 会直接影响模型是否能正确调用它。

初学时可以这样理解：

LLM 负责判断“现在该不该调用工具、该传什么参数”；
Agno 负责把 Python 函数或 Toolkit 包装成模型能看懂的 schema；
工具函数负责真正执行外部动作；
工具结果再回到模型上下文里，继续生成最终回答。

这比“给模型一个插件”更严肃。因为工具一旦能写数据库、发邮件、下单、删文件、发消息，它就不再是展示能力，而是进入了业务系统的权限边界。

2.1 工具函数怎么写

一个好的工具函数，至少满足五点：

要点 原因
函数名清晰 模型会根据名字判断用途
参数有类型注解 Agno 可以构建更明确的工具 schema
docstring 写清楚使用场景 这是给模型看的说明书
返回结构化结果 方便模型继续推理和引用
副作用明确 写文件、发请求、改数据库都要被标出来

比如一个记录跟进事项的工具可以这样写：

from datetime import datetime, timezone
from typing import Literal
import json


def record_follow_up(
    owner: str,
    task: str,
    priority: Literal["P0", "P1", "P2"] = "P1",
) -> str:
    """Record a follow-up action item after the user asks for one.

    Args:
        owner: Person or team responsible for the follow-up.
        task: Concrete action that should be tracked.
        priority: P0 for urgent, P1 for normal, P2 for low priority.
    """
    item = {
        "owner": owner,
        "task": task,
        "priority": priority,
        "created_at": datetime.now(timezone.utc).isoformat(),
    }
    with open("support_action_items.jsonl", "a", encoding="utf-8") as f:
        f.write(json.dumps(item, ensure_ascii=False) + "\n")
    return f"Recorded follow-up for {owner}: {task} ({priority})"

这里的重点不是这段代码多复杂，而是它的边界很清楚：

  • 只有一个动作：记录跟进事项。
  • 参数都是业务可理解的词。
  • priority 用 Literal 限制枚举。
  • docstring 明确说明“用户要求后才记录”。
  • 返回值是明确确认，不让 Agent 猜执行结果。

2.2 工具不是越多越好

很多人做 Agent 的第一反应是“把能接的工具都接上”。这通常会带来三个问题。

第一，选择空间变大。模型看到几十个工具时，会更难判断该用哪个，尤其是工具名和参数描述不清楚时。

第二，权限面扩大。一个只需要查知识库的客服 Agent，不应该顺手拥有删除订单、修改用户等级、批量发邮件的能力。

第三，排错更困难。回答错了，你很难判断是模型理解错、检索错、工具错，还是工具之间互相干扰。

Agno 官方示例里有两个很实用的控制点：

tool_choice="auto"       # 让模型自己决定是否调用工具
tool_choice="none"       # 禁止工具调用
tool_call_limit=1        # 限制一次运行最多调用几个工具

工具治理的基本原则可以写成一句话：

只暴露当前任务需要的最小工具集；只读工具默认允许；写操作需要明确触发；高风险工具要审批。

3. Knowledge：Agentic RAG 不是“把资料塞进 prompt”

第二块是 Knowledge，也就是知识库。

Agno 官方文档对 Agent with Knowledge 的说明很直接：Knowledge 给 Agent 一个运行时可搜索的知识库，这种模式叫 Agentic RAG，Agent 会根据用户问题决定什么时候搜索。

这和传统 RAG 的区别在于：

传统 RAG：
用户问题 -> 系统固定检索 -> 拼接上下文 -> 调模型

Agentic RAG：
用户问题 -> Agent 判断是否需要检索 -> 调用知识库搜索工具 -> 基于结果继续回答

看起来只是顺序差异，工程含义却很不同。

在传统 RAG 中，检索通常是固定前置步骤。无论用户问什么，系统都先查一遍知识库。这样简单、稳定、容易评估，但灵活性有限。

在 Agentic RAG 中，知识库搜索变成 Agent 可以主动调用的工具。它可以先判断问题是否需要外部资料，也可以在回答中途发现信息不足再检索。灵活性更高，但也带来新问题：模型可能忘记检索、检索太多、检索错方向，或者把低质量片段当成证据。

3.1 Agno 的 Knowledge 基础结构

官方示例大概是这种结构：

from agno.knowledge.embedder.openai import OpenAIEmbedder
from agno.knowledge.knowledge import Knowledge
from agno.vectordb.lancedb import LanceDb, SearchType

knowledge = Knowledge(
    vector_db=LanceDb(
        uri="tmp/lancedb",
        table_name="recipes",
        search_type=SearchType.hybrid,
        embedder=OpenAIEmbedder(id="text-embedding-3-small"),
    ),
)

knowledge.insert(
    url="https://example.com/document.pdf",
)

它背后有几件事：

组件 作用
Reader 读取 PDF、文本、URL 等内容
Chunking 把文档切成适合检索的片段
Embedder 把文本转成向量
Vector DB 存储向量并支持相似度检索
SearchType 控制语义、关键词或混合检索
Agent search tool 让 Agent 在需要时搜索知识库

Agno 文档里的 LanceDB 示例使用 SearchType.hybrid，也就是语义检索和关键词检索结合。这个细节很重要：很多企业知识库里有版本号、错误码、产品名、客户 ID、配置项，单靠语义检索容易漏掉；只靠关键词检索又抓不住同义表达。混合检索通常是更稳的起点。

3.2 Knowledge 的三个常见坑

第一个坑是“资料越多越好”。不是。知识库越大，越需要元数据、过滤条件、chunk 策略和评测集。否则 Agent 查到的可能只是“看起来相关”的片段。

第二个坑是“不区分知识来源”。正式手册、历史工单、Slack 讨论、个人笔记的可信度不同。生产环境里最好给知识片段加来源、时间、版本、作者、业务线等 metadata。

第三个坑是“检索结果直接当真”。RAG 不是证明系统。Agent 应该告诉用户依据来自哪里、是否有资料缺口、哪些结论需要人工确认。

我更建议初期把 Knowledge 当成“受控证据池”，而不是“万能知识外挂”。

4. Storage：会话历史不是 Memory

很多人会把 Storage 和 Memory 混在一起。Agno 文档分得很清楚：

能力 保存什么 作用范围 典型问题
Storage conversation history 按 session “刚才我们说到哪？”
Memory user preferences and facts 按 user 跨会话 “这个用户长期偏好什么？”

先说 Storage。

Storage 解决的是会话连续性。比如第一轮用户问：

帮我分析知识库检索慢的问题。

第二轮用户接着问：

刚才你说的第一步为什么优先？

如果没有 Storage 和历史上下文，Agent 很可能不知道“刚才”指什么。Agno 的 Agent with Storage 示例展示了这种写法：

from agno.db.sqlite import SqliteDb

db = SqliteDb(db_file="tmp/agents.db")

agent = Agent(
    db=db,
    add_history_to_context=True,
    num_history_runs=5,
)

agent.print_response("Give me a quick analysis of NVIDIA", session_id="finance-session")
agent.print_response("Compare that to AMD", session_id="finance-session")

关键参数是：

  • db：保存运行、会话等状态。
  • session_id：同一个会话线程。
  • add_history_to_context=True：把历史消息放回上下文。
  • num_history_runs=5：控制最多带入多少轮历史。

为什么要限制历史轮数？因为上下文不是垃圾桶。历史越多，成本越高，噪声越多，模型越可能被无关旧信息带偏。

5. Memory：长期记忆要少而准

Memory 解决的是另一个问题：用户长期事实或偏好。

比如：

这个用户偏好中文回答。
这个用户是平台工程师。
这个用户关注私有化部署和安全审计。
这个用户不希望 Agent 自动执行写操作。

这些信息不属于某一次会话，而是跨会话都可能有用。Agno 官方 Agent with Memory 示例里，MemoryManager 和 enable_agentic_memory=True 会让 Agent 具备更新用户记忆的能力。

但 Memory 是一把双刃剑。它带来个性化，也带来治理问题：

  • 什么可以记？
  • 谁可以看？
  • 用户能不能删除？
  • 记错了怎么改？
  • 是否会把短期上下文误提升为长期事实？

我自己的建议是：第二篇实践先不自动启用长期 Memory，只使用 Storage 保存会话历史。等你把工具和知识库跑稳，再进入长期 Memory。因为长期记忆一旦质量差，会持续污染后续对话。

一个实用规则是：

Storage 默认可开；Memory 谨慎开启。

6. 四块能力合起来：一个可用 Agent 的最小架构

到这里，Agno Agent 的可用结构就比较清楚了：

用户问题
  -> Agent 读取当前指令、会话历史、用户上下文
  -> 判断是否需要搜索 Knowledge
  -> 如需检索，调用 knowledge search tool
  -> 判断是否需要业务工具
  -> 如需执行，调用受限工具
  -> 组合证据、工具结果和历史上下文
  -> 输出答案
  -> 会话写入 Storage
  -> 必要时更新 Memory 或记录学习

这一套里面，模型只是一个决策器。真正让系统稳定的是边界：

  • Knowledge 限定依据来源。
  • Tools 限定动作范围。
  • Storage 限定会话连续性。
  • Memory 限定长期用户事实。
  • Tracing 限定排错路径。
  • Approval 限定高风险动作。

如果没有这些边界，Agent 很像一个很聪明但没有岗位职责的人：它什么都想帮忙，但你很难放心把真实系统交给它。

7. 实践：做一个技术支持知识库 Agent

下面做一个小实践，目标不是炫技，而是把 Tools、Knowledge、Storage 三件事组合起来。

它会：

  1. 把几段技术支持手册写入本地知识库。
  2. 使用 LanceDB 做本地向量库。
  3. 使用 SQLite 保存会话历史。
  4. 暴露一个 record_follow_up 自定义工具。
  5. 要求 Agent 先查知识库，再回答。
  6. 只有当用户明确要求“记录/保存/跟进”时才调用写工具。

7.1 安装依赖

uv venv --python 3.12
source .venv/bin/activate
uv pip install -U agno openai lancedb sqlalchemy
export OPENAI_API_KEY="your_openai_api_key_here"

如果你不想发送 Agno 遥测事件，可以按官方 README 说明关闭：

export AGNO_TELEMETRY=false

如果你没有 gpt-5.2 权限，把代码里的模型 ID 改成你当前可用、并且支持工具调用的模型。

7.2 完整代码

保存为 support_playbook_agent.py：

from __future__ import annotations

import json
from datetime import datetime, timezone
from pathlib import Path
from typing import Literal

from agno.agent import Agent
from agno.db.sqlite import SqliteDb
from agno.knowledge.embedder.openai import OpenAIEmbedder
from agno.knowledge.knowledge import Knowledge
from agno.knowledge.reader.text_reader import TextReader
from agno.models.openai import OpenAIResponses
from agno.vectordb.lancedb import LanceDb, SearchType


ROOT = Path(__file__).parent
TMP = ROOT / "tmp"
TMP.mkdir(exist_ok=True)

ACTION_FILE = TMP / "support_action_items.jsonl"


PLAYBOOKS = [
    {
        "title": "知识库检索慢的排查手册",
        "body": """
当用户反馈 RAG 或知识库检索慢时，优先检查四类问题：
1. 文档切分是否过碎，导致检索候选过多。
2. 向量库是否只做语义检索，缺少关键词或 hybrid search。
3. top_k 是否过大，导致过多上下文塞进模型。
4. 是否每次请求都重复写入或重建索引。

推荐处理顺序：
先确认是否重复 ingest，再看向量库查询耗时，然后调小 max_results，
最后再评估 chunking、embedding 模型和 rerank。
""",
    },
    {
        "title": "工具调用安全边界",
        "body": """
给 Agent 暴露工具时，默认采用最小权限：
只暴露当前任务真正需要的工具；写操作要有明确确认；危险工具要有审批；
工具返回值要结构化，方便模型继续推理；生产环境要记录 tool call、参数和耗时。

如果一个工具会写数据库、发邮件、下单、删除文件或触达外部用户，
应当被视为高风险工具，不能和普通只读查询工具混在一起。
""",
    },
    {
        "title": "会话历史与用户记忆的区别",
        "body": """
Storage 保存的是一次会话的历史，适合回答“刚才我们讨论了什么”。
Memory 保存的是跨会话的用户事实或偏好，适合回答“这个用户长期偏好什么”。

不要把所有聊天历史都塞进 Memory。能从 session history 里恢复的内容，
通常不应该提升成长期记忆。长期记忆应当少而准，并允许用户查看、修改和删除。
""",
    },
]


db = SqliteDb(db_file=str(TMP / "agents.db"))

knowledge = Knowledge(
    name="Support Playbook",
    vector_db=LanceDb(
        uri=str(TMP / "lancedb"),
        table_name="support_playbook",
        search_type=SearchType.hybrid,
        embedder=OpenAIEmbedder(id="text-embedding-3-small"),
    ),
    max_results=4,
    contents_db=db,
)


def seed_knowledge() -> None:
    """Insert the demo playbooks into the local knowledge base."""
    for doc in PLAYBOOKS:
        knowledge.insert(
            name=doc["title"],
            text_content=doc["body"],
            reader=TextReader(),
            skip_if_exists=True,
        )


def record_follow_up(
    owner: str,
    task: str,
    priority: Literal["P0", "P1", "P2"] = "P1",
) -> str:
    """Record a follow-up action item after the user asks for one.

    Args:
        owner: Person or team responsible for the follow-up.
        task: Concrete action that should be tracked.
        priority: P0 for urgent, P1 for normal, P2 for low priority.
    """
    item = {
        "owner": owner,
        "task": task,
        "priority": priority,
        "created_at": datetime.now(timezone.utc).isoformat(),
    }
    with ACTION_FILE.open("a", encoding="utf-8") as f:
        f.write(json.dumps(item, ensure_ascii=False) + "\n")
    return f"Recorded follow-up for {owner}: {task} ({priority})"


support_agent = Agent(
    id="support-playbook-agent",
    name="Support Playbook Agent",
    model=OpenAIResponses(id="gpt-5.2"),
    knowledge=knowledge,
    search_knowledge=True,
    tools=[record_follow_up],
    db=db,
    add_history_to_context=True,
    num_history_runs=5,
    add_datetime_to_context=True,
    tool_call_limit=4,
    instructions=[
        "你是一个谨慎的技术支持知识库助手。",
        "回答前先搜索知识库，优先依据知识库内容给出步骤。",
        "如果用户明确要求记录、创建、保存或跟进事项，才调用 record_follow_up。",
        "不要编造不存在的内部流程；资料不足时说明缺口，并给出下一步排查建议。",
        "输出使用中文 Markdown，包含：判断、排查步骤、风险提醒、是否需要跟进。",
    ],
    markdown=True,
    debug_mode=True,
)


if __name__ == "__main__":
    seed_knowledge()

    session_id = "demo-support-session"
    user_id = "demo-user"

    support_agent.print_response(
        "客户反馈私有化部署后知识库检索变慢。请给一个排查顺序；"
        "如果需要跟进，请记录给平台组，优先级 P1。",
        session_id=session_id,
        user_id=user_id,
        stream=True,
    )

    support_agent.print_response(
        "刚才你建议先检查哪两件事？为什么？",
        session_id=session_id,
        user_id=user_id,
        stream=True,
    )

7.3 这段代码在做什么

先看 Knowledge：

knowledge = Knowledge(
    vector_db=LanceDb(...),
    max_results=4,
    contents_db=db,
)

这里用 LanceDB 做本地向量库，用 OpenAIEmbedder 做 embedding，用 SearchType.hybrid 做混合检索。max_results=4 是一个很好的提醒：不要把太多知识片段塞进上下文。上下文越多不一定越准，很多时候只是越吵。

再看 seed_knowledge()：

knowledge.insert(
    name=doc["title"],
    text_content=doc["body"],
    reader=TextReader(),
    skip_if_exists=True,
)

这对应官方文档里 knowledge.insert(url/path/text_content) 的用法。生产环境里可以把 text_content 换成 PDF、网页、S3、GCS、数据库文档等来源，但原则相同：先 ingest，再检索。

然后是自定义工具：

tools=[record_follow_up]

这说明 Agno 不要求你把所有工具都做成复杂类。一个普通 Python 函数，只要命名、类型和 docstring 写得清楚，就可以成为模型可调用工具。

最后是 Storage：

db=db,
add_history_to_context=True,
num_history_runs=5,

这让第二轮问题“刚才你建议先检查哪两件事”能够接上第一轮上下文。没有这组设置，Agent 可能只看到一个孤零零的“刚才”，然后开始凭空补全。

7.4 为什么这个例子有意限制工具调用

代码里有一行：

tool_call_limit=4

这不是装饰。生产 Agent 必须有资源和行为边界。

如果工具是只读查询，限制可以宽一点；如果工具有写操作，限制应该更严格。比如这个例子里 record_follow_up 会写本地 JSONL 文件，所以 instruction 里明确写了：

如果用户明确要求记录、创建、保存或跟进事项，才调用 record_follow_up。

这就是一种轻量的工具治理。

更严肃的生产系统里，还应该加：

  • 写操作二次确认。
  • 高风险工具 human approval。
  • 工具参数校验。
  • 工具执行审计。
  • 失败重试与幂等键。
  • 按用户角色动态暴露工具。

Agno 后面可以通过 AgentOS、Approvals、Authorization、Tracing、MCPServerConfig 等机制继续加强这件事。第二篇先把心智模型建立起来。

8. 从这个例子推广：什么时候用 Tools、Knowledge、Storage、Memory

可以用这张表做判断：

需求 应该用什么 不该怎么做
Agent 需要查实时外部数据 Tools / Toolkit 把过期数据写死进 prompt
Agent 需要查企业文档 Knowledge 把整本文档塞进系统提示词
用户会连续追问 Storage 让模型猜“刚才”指什么
用户有长期偏好 Memory 把所有聊天历史都当长期记忆
工具有写操作 Tools + approval / limit 让模型自由执行
上线后要排错 Tracing / logs 只看最终回答
多入口调用 Agent AgentOS API / MCP 每个入口单独复制一套逻辑

这也是 Agno 和很多轻量 Agent wrapper 的区别。它不只关心“这一轮模型怎么回答”，还关心：

  • 运行状态放哪里。
  • 工具调用怎么记录。
  • Agent 如何变成 API。
  • 如何接 Slack、Telegram、WhatsApp、AG-UI、A2A、MCP。
  • 如何做 tracing、authorization、scheduler。
  • 如何在 Control Plane 里管理运行态。

9. 生产化时最容易忽略的五个细节

9.1 工具返回值要可被模型消费

不要让工具返回一大段格式混乱的日志。最好返回 JSON、短文本、表格或明确状态。

坏例子：

done

好例子：

{
  "status": "created",
  "action_id": "act_20260803_001",
  "owner": "platform-team",
  "priority": "P1"
}

模型看到后能继续解释，也方便前端展示。

9.2 Knowledge 要有版本意识

企业文档会过期。一个 2024 年的部署手册，可能已经不适用于 2026 年的产品。

知识库片段最好带上：

  • 来源 URL 或文件名。
  • 文档版本。
  • 更新时间。
  • 业务线。
  • 可见范围。
  • 是否已废弃。

如果缺少这些 metadata，Agent 看起来在引用知识库，实际上可能在引用“历史包袱”。

9.3 Storage 不是越长越好

num_history_runs 要根据任务设置。客服排障可能需要最近 5 到 10 轮；一次性数据问答可能只要 2 到 3 轮；代码生成长会话可能需要摘要机制。

上下文历史的价值会衰减，但 token 成本不会自动衰减。

9.4 Memory 要允许纠错

如果 Agent 记住了“用户偏好英文回答”，但用户后来改成长期希望中文回答，系统必须允许更新。记忆系统没有编辑和删除能力，会很快从个性化变成污染源。

Agno AgentOS 的 Memory API 提供了 create/list/update/delete 等操作，这一点在做产品时很重要。

9.5 Tracing 是上线前就该加的

Agno 的 AgentOS tracing 文档说明，tracing=True 可以记录 run、模型调用、工具调用、团队协作、workflow step 等 span，并存入 Agno database。

这不是锦上添花。没有 tracing，你只能看到“最终答案错了”。有 tracing，你能看到：

  • Agent 有没有查知识库。
  • 查到了哪些片段。
  • 调了哪个工具。
  • 工具参数是什么。
  • 哪一步耗时最长。
  • 哪一步报错。

这会决定你是盲修 prompt，还是能真正定位系统问题。

10. 第二篇小结：Agno 的关键不是“会调工具”，而是边界清楚

这一篇我们把 Agno 的基础能力往前推了一步。

第一篇里，Agent 像一个会读目录的小助手。第二篇里，它开始像一个可以接入业务知识和业务动作的小系统：

  • Tools 让它能做事。
  • Knowledge 让它有依据。
  • Storage 让它能接住多轮上下文。
  • Memory 让它未来能理解用户长期偏好。
  • tool choice、tool call limit、instruction 让它不至于乱动。
  • AgentOS、Tracing、MCP 给后续服务化和治理留下接口。

我的判断是：Agno 最近真正值得关注的，不是它能不能写一个简单 Agent。简单 Agent 现在很多框架都能写。

它更有价值的地方在于：它把 Agent 周边那些“不性感但很要命”的工程能力放到了主线上，包括 storage、knowledge、memory、approval、tracing、authorization、scheduler、MCP、部署模板和 Control Plane。

如果你只是写一个周末 demo，可能感受不明显。

但如果你要把 Agent 接进客服、数据分析、代码平台、企业知识库、内部自动化系统，这些能力会从“可选项”变成“救命绳”。

下一篇我会继续沿着系列往下走，重点讲 Agno 的 Storage、Memory 与 Learning：Agent 怎么从“每次重新认识你”，变成“在可控边界里持续改进”。

参考来源

  • Agno GitHub 主仓：https://github.com/agno-agi/agno
  • Agno README：https://github.com/agno-agi/agno/blob/main/README.md
  • Agno PyPI：https://pypi.org/project/agno/
  • Agno v2.8.6 Release：https://github.com/agno-agi/agno/releases/tag/v2.8.6
  • Agno Docs Index：https://docs.agno.com/llms.txt
  • Agent with Tools：https://docs.agno.com/agents/usage/agent-with-tools
  • Agent with Knowledge：https://docs.agno.com/agents/usage/agent-with-knowledge
  • Agent with Storage：https://docs.agno.com/agents/usage/agent-with-storage
  • Agent with Memory：https://docs.agno.com/agents/usage/agent-with-memory
  • Agentic RAG example：https://docs.agno.com/examples/agents/knowledge/agentic-rag
  • Custom Tool for Self-Learning：https://docs.agno.com/examples/basics/custom-tool-for-self-learning
  • Tool Call Limit：https://docs.agno.com/examples/agents/tools/tool-call-limit
  • Tool Choice：https://docs.agno.com/examples/agents/tools/tool-choice
  • AgentOS Runtime：https://docs.agno.com/agent-os/overview
  • AgentOS Tracing：https://docs.agno.com/agent-os/tracing/overview
  • AgentOS as MCP Server：https://docs.agno.com/agent-os/mcp/mcp
  • Agno cookbook README：https://github.com/agno-agi/agno/blob/main/cookbook/README.md
# 人工智能 # RAG
Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

cover

大模型安全实战】智能体安全的攻防二元性：同一种能力，为什么既是防线也是攻击面？（第4期）

avatar 龙虾开发者社区

AI Agent大厂高频面试题5

https://mp.weixin.qq.com/s/CV-8d8N0oga58sMebW2eNw

avatar 龙虾开发者社区
cover

SparkSQL 之 Hive On Spark 原理分析

avatar 龙虾开发者社区