agno 学习组件手工组装指南用 LearningMachine 的三块表面构建你自己的记忆注入【免费下载链接】agnoBuild, run, and manage agent platforms.项目地址: https://gitcode.com/GitHub_Trending/ag/agno本文是 agno 仓库中 cookbook/08_learning/11_composition 系列的技术解读。该目录展示了与learning自动注入相对的另一条路线——手工之门The Manual Door不传learning由开发者自己把LearningMachine的三个公开表面捕获工具、指导指令、召回数据精确放进 Agent 的对应位置。读完本文你将掌握 LearningMachine 与 FileSystem、自定义 system prompt 组合编排的完整模式理解每条捕获路径本质是一次模型调用model为什么必不可少并学会用capture_hook()在手工之门上补充 ALWAYS 模式的后台提取。两扇门自动之门与手工之门agno 的LearningMachine源码位于 libs/agno/agno/learn/machine.py是统一的 Agent 学习编排器协调多类学习存储用户画像User Profile、用户记忆User Memory、会话上下文Session Context、实体记忆Entity Memory、习得知识Learned Knowledge以及决策日志Decision Log。接入方式有两条自动之门向Agent传入learning框架会在固定的位置自动注入上下文、指令和工具你无需关心注入点。手工之门完全不传learning框架什么都不注入。你像FileSystem组合那样自己把机器人的三块公开表面放到想放的位置。11_composition目录的意义就是与00_quickstart自动之门见 cookbook/08_learning/00_quickstart并排阅读看清两扇门的差异自动之门省事但位置固定手工之门琐碎但完全可控尤其适合把 LearningMachine、FileSystem 和自己的 system prompt 按一个能一眼读懂的顺序组合起来——没有任何东西在背后偷偷附加。三块表面get_tools / instructions / build_context手工之门的全部操作对象是LearningMachine暴露的三个公开方法。README 中的对照表如下表面返回内容放置位置learning.get_tools(user_id...)捕获工具tools[...]learning.instructions()指导指令块如何使用这些工具instructions[...]learning.build_context(user_id..., message...)召回的已有数据additional_context/ 依赖注入在 machine.py 的get_tools()实现中可以看到返回的工具按启用的 store 汇聚user_profile→update_profileuser_memory→update_user_memoryentity_memory→remember_about、link_entities、search_entities、forgetlearned_knowledge→search_learnings、save_learninginstructions()是实例方法而非静态字符串machine.py指导文本依启用的 store 及其模式mode动态聚合所以必须按机器实例计算。build_context()则调用recall()汇总各 store 的召回结果并格式化为上下文字符串machine.py。自动路径在注入点把指令块与数据块拼接手工之门则把二者分别放到你想放的位置。build_context()支持的关键参数源码签名见 machine.pyuser_id用户标识用于用户画像/记忆查找session_id会话标识用于会话上下文查找message当前消息用于学习的语义检索entity_id/entity_type要检索的实体namespace实体记忆与习得知识的命名空间过滤agent_id/team_id可选的 Agent / Team 上下文实战一basic.py —— 三表面全部手工放置basic.py 是最小手工之门示例创建LearningMachine时显式传入db与model启用 AGENTIC 模式的用户记忆与实体记忆from agno.agent import Agent from agno.db.postgres import PostgresDb from agno.learn import LearningMachine, LearningMode, UserMemoryConfig from agno.models.openai import OpenAIResponses db PostgresDb(db_urlpostgresqlpsycopg://ai:ailocalhost:5532/ai) learning LearningMachine( dbdb, modelOpenAIResponses(idgpt-5.5), user_memoryUserMemoryConfig(modeLearningMode.AGENTIC), entity_memoryTrue, ) USER_ID composerexample.com agent Agent( modelOpenAIResponses(idgpt-5.5), dbdb, tools[*learning.get_tools(user_idUSER_ID)], instructions[ You are a research assistant., learning.instructions(), ], user_idUSER_ID, markdownTrue, ) if __name__ __main__: agent.print_response( Remember that I prefer sources with primary data, and track the Meridian project - Priya runs it., streamTrue, ) print(\n--- what the manual door placed (guidance data) ---) print(learning.instructions()[:400]) print(...) print(learning.build_context(user_idUSER_ID, messagewhat about meridian?))注意几点没有learning就没有自动捕获Agent 捕获记忆的唯一途径是调用你通过get_tools()交给它的工具。这就是 README 强调的手工之门天生具备 agentic 属性——学习动作由 Agent 自主决定何时调用。实体记忆默认 AGENTIC 模式见 machine.py 的默认配置构造这与session_context文档自称 ALWAYS-only 形成对照。代码末尾直接打印instructions()与build_context()把门上放了两块什么直观展示出来。根据 TEST_LOG.md 的记录在修复缺失model的问题后本示例运行结果是 PASS无learning时手工放置的工具成功捕获了用户偏好用户记忆与 Meridian 项目 Priya 关联实体记忆打印的手工之门表面显示出指导块以及一个数据块——对消息 what about meridian? 的召回将 Meridian 连同 runs - Priya 的一跳边一起带出。实战二with_filesystem.py —— 与 FileSystem 的刻意顺序with_filesystem.py 展示了手工之门的核心价值LearningMachine、FileSystem 与自定义 system prompt 以可以在页面上直接读出来的顺序组合learning LearningMachine( dbdb, modelOpenAIResponses(idgpt-5.5), # the manual door injects nothing user_memoryUserMemoryConfig(modeLearningMode.AGENTIC), ) fs FileSystem(db, namespacecomposition-notes) USER_ID composerexample.com agent Agent( modelOpenAIResponses(idgpt-5.5), dbdb, tools[*learning.get_tools(user_idUSER_ID), fs.tools()], instructions[ You are a research assistant. Keep running notes on topics you research., learning.instructions(), fs.instructions(), ], user_idUSER_ID, markdownTrue, )这是一个精心安排的顺序学习工具 文件系统工具 两段指令块。Agent 收到记录向量数据库对比周五截止的请求后既会写笔记文件FileSystem也会把每个总结中结论优先的偏好写进用户记忆。TEST_LOG 补充了一个非常值得注意的模型行为观察Agent 在把偏好写进笔记的同时也把结论优先这一偏好本身写进了笔记——一主张一归属one-claim-one-home的纪律正是 second-brain 指令在 FileSystem 之上叠加出来的效果。也就是说指令块不只是摆设它确实在改变 Agent 的落盘行为。实战三context_block.py —— 只要数据块不要工具context_block.py 演示第三个表面单独使用只注入build_context()返回的数据块不注入任何工具得到一个对机器所知内容的只读视图learning LearningMachine( dbdb, modelOpenAIResponses(idgpt-5.5), # the manual door injects nothing user_memoryUserMemoryConfig(modeLearningMode.AGENTIC), ) USER_ID composerexample.com # Seed a memory through the data API so the read-only agent has something to see store learning.user_memory_store store.get_tools(user_idUSER_ID)0 # No learning, no tools: just the data block, placed as additional context agent Agent( modelOpenAIResponses(idgpt-5.5), dbdb, additional_contextlearning.build_context(user_idUSER_ID), user_idUSER_ID, markdownTrue, )要点通过learning.user_memory_store拿到 store再直接调用其工具完成一次播种seed让只读 Agent 有数据可看。Agent 不配置learning、不配置tools仅把数据块放进additional_context。TEST_LOG 对此模式的结论是数据块能提供信息但不能强迫模型——重跑验证中播种成功落地后模型依然先列要点、后给结论说明纯数据块只提供信息而不强制结论这一原始观察在修正后依然成立。实战四always_capture.py —— 手工之门上的 ALWAYS 逃生舱always_capture.py 解决一个矛盾手工之门默认没有自动后处理提取捕获全靠工具但如果你既要手工放置的提示词、又要 ALWAYS 模式的后台提取呢答案是capture_hook()learning LearningMachine( dbdb, modelOpenAIResponses(idgpt-5.5), user_profileTrue, user_memoryTrue ) USER_ID composerexample.com agent Agent( modelOpenAIResponses(idgpt-5.5), dbdb, instructions[You are a helpful assistant.], post_hooks[learning.capture_hook()], user_idUSER_ID, markdownTrue, ) if __name__ __main__: agent.print_response( Im Dana, a data engineer in Lisbon. I mostly work on our ClickHouse pipelines., streamTrue, ) time.sleep(10) print(\n--- what ALWAYS capture extracted ---) learning.user_profile_store.print(user_idUSER_ID) learning.user_memory_store.print(user_idUSER_ID)capture_hook()源码见 machine.py返回一个兼容post_hooks的可调用对象内部包裹机器的捕获流程若有background_executor则提交到后台执行器与learning相同的运行位置不阻塞响应路径否则内联执行同步、异步运行都适用。异步场景另有acapture_hook()machine.py把aprocess作为 fire-and-forget 任务调度失败只记日志、绝不抛进运行过程。TEST_LOG 的验证结果是 PASSpost_hooks[learning.capture_hook()]触发了 ALWAYS 提取没有发生任何工具调用就出现了画像Name/Preferred Name: Dana和一条记忆数据工程师、里斯本、ClickHouse 管道。README 明确评价这是逃生舱而非第三种形态——它不是与自动、手工并列的新方式而是在手工之门上补回 ALWAYS 提取的手段。一个反复踩过的坑手工之门不注入任何东西model必须显式给出这是整个11_composition目录的 TEST_LOG 中反复出现、并最终形成工程改进的核心教训。现象模型缺失导致静默失败手工之门不注入任何东西意味着机器上持有的是构造它时给定的db与model。而每一条捕获路径本质上都是一次模型调用update_profile、update_user_memory在无模型时返回 No model providedcapture_hook()的 ALWAYS 提取在无模型时什么都不存实体记忆在无模型时保留每一个陈述过的事实而不会淘汰它矛盾的那些。TEST_LOG 记录了两次重要的 2026-07-26 修正恰恰证明了这种静默失败的隐蔽性basic.py首份日志对用户记忆的判断是错的。机器未带modelupdate_user_memory返回 No model provided什么都没存——只有实体写入无需模型落地了。补上model重跑后update_user_memory才存下 Prefers sources with primary data并在 learnings 表中得到验证。with_filesystem.py同样缺model笔记写入了但偏好没有存储。补上后update_user_memory与append_file双双触发。context_block.py此前把播种的上下文里明明有记忆总结却把结论放最后解读为模型失败实际是存储失败——播种调用也需要模型导致什么都没播进去、上下文块是空的。补上model后种子落地。always_capture.py首跑因空存储而 FAIL——手工之门不注入机器必须显式传model该文件与 README 现在已写明这一点。工程改进attach 时就警告always_capture.py是当时唯一学乖了的文件而LearningMachine.get_tools()现在会在某个需要通过模型捕获的 store 没有模型时警告一次_warn_if_model_missing()见 machine.py列出无法捕获的 store提示工具会返回 No model provided、实体记忆会保留全部事实而不淘汰矛盾项并给出两条出路——给LearningMachine显式传model或改用learning让机器复用 Agent 的模型。这样下一个人是在挂载attach时发现问题而不是等到查空表才发现。别混用两扇门双份渲染警告README 与源码都明确了一条边界同一个机器既传给learning又手工放置它的表面会让指令块和数据块渲染两遍。instructions()调用时会把机器标记为手工放置_placed_by_hand True见 machine.py若框架随后又通过自动注入路径拉取指令_framework_instructions()会检测到该标记并警告一次双份渲染machine.py提示二选一传learning走自动路径或自己放置表面且不传learning。运行方式与环境前提各示例文件头部均给出运行命令例如.venvs/demo/bin/python cookbook/08_learning/11_composition/basic.py四个文件的运行命令依次为basic.py、with_filesystem.py、context_block.py、always_capture.py路径同上。前提条件需要一个可用的 Postgres 数据库示例默认postgresqlpsycopg://ai:ailocalhost:5532/aiTEST_LOG 记录为 pgvector 容器跑在 5532 端口学习存储均持久化于该库。需要可访问的 OpenAI 兼容模型示例用gpt-5.5的OpenAIResponses。根据 TEST_LOG测试针对 gpt-5.5OpenAIResponses在分支feat/entity-memory-revamp上完成2026-07-26 在修复缺失模型问题后复测四个示例全部 PASS。小结手工之门的使用决策场景选择想省事接受框架固定注入位置learning自动之门要把学习、文件系统、自定义提示词按明确顺序组合手工之门 三表面手放只要召回数据、不要捕获工具只读仅build_context()放入additional_context手工提示词 ALWAYS 后台提取post_hooks[learning.capture_hook()]无论走哪扇门请记住手工之门的铁律它不注入任何东西——db与model必须显式交给机器否则捕获会静默失败同一机器不要同时走两扇门否则内容渲染双份。理解了这两条你就能像 FileSystem 那样把学习能力精确地编排进任何 Agent。【免费下载链接】agnoBuild, run, and manage agent platforms.项目地址: https://gitcode.com/GitHub_Trending/ag/agno创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 agno 学习组件手工组装指南：用 LearningMachine 的三块表面构建你自己的记忆注入
agno 学习组件手工组装指南用 LearningMachine 的三块表面构建你自己的记忆注入【免费下载链接】agnoBuild, run, and manage agent platforms.项目地址: https://gitcode.com/GitHub_Trending/ag/agno本文是 agno 仓库中 cookbook/08_learning/11_composition 系列的技术解读。该目录展示了与learning自动注入相对的另一条路线——手工之门The Manual Door不传learning由开发者自己把LearningMachine的三个公开表面捕获工具、指导指令、召回数据精确放进 Agent 的对应位置。读完本文你将掌握 LearningMachine 与 FileSystem、自定义 system prompt 组合编排的完整模式理解每条捕获路径本质是一次模型调用model为什么必不可少并学会用capture_hook()在手工之门上补充 ALWAYS 模式的后台提取。两扇门自动之门与手工之门agno 的LearningMachine源码位于 libs/agno/agno/learn/machine.py是统一的 Agent 学习编排器协调多类学习存储用户画像User Profile、用户记忆User Memory、会话上下文Session Context、实体记忆Entity Memory、习得知识Learned Knowledge以及决策日志Decision Log。接入方式有两条自动之门向Agent传入learning框架会在固定的位置自动注入上下文、指令和工具你无需关心注入点。手工之门完全不传learning框架什么都不注入。你像FileSystem组合那样自己把机器人的三块公开表面放到想放的位置。11_composition目录的意义就是与00_quickstart自动之门见 cookbook/08_learning/00_quickstart并排阅读看清两扇门的差异自动之门省事但位置固定手工之门琐碎但完全可控尤其适合把 LearningMachine、FileSystem 和自己的 system prompt 按一个能一眼读懂的顺序组合起来——没有任何东西在背后偷偷附加。三块表面get_tools / instructions / build_context手工之门的全部操作对象是LearningMachine暴露的三个公开方法。README 中的对照表如下表面返回内容放置位置learning.get_tools(user_id...)捕获工具tools[...]learning.instructions()指导指令块如何使用这些工具instructions[...]learning.build_context(user_id..., message...)召回的已有数据additional_context/ 依赖注入在 machine.py 的get_tools()实现中可以看到返回的工具按启用的 store 汇聚user_profile→update_profileuser_memory→update_user_memoryentity_memory→remember_about、link_entities、search_entities、forgetlearned_knowledge→search_learnings、save_learninginstructions()是实例方法而非静态字符串machine.py指导文本依启用的 store 及其模式mode动态聚合所以必须按机器实例计算。build_context()则调用recall()汇总各 store 的召回结果并格式化为上下文字符串machine.py。自动路径在注入点把指令块与数据块拼接手工之门则把二者分别放到你想放的位置。build_context()支持的关键参数源码签名见 machine.pyuser_id用户标识用于用户画像/记忆查找session_id会话标识用于会话上下文查找message当前消息用于学习的语义检索entity_id/entity_type要检索的实体namespace实体记忆与习得知识的命名空间过滤agent_id/team_id可选的 Agent / Team 上下文实战一basic.py —— 三表面全部手工放置basic.py 是最小手工之门示例创建LearningMachine时显式传入db与model启用 AGENTIC 模式的用户记忆与实体记忆from agno.agent import Agent from agno.db.postgres import PostgresDb from agno.learn import LearningMachine, LearningMode, UserMemoryConfig from agno.models.openai import OpenAIResponses db PostgresDb(db_urlpostgresqlpsycopg://ai:ailocalhost:5532/ai) learning LearningMachine( dbdb, modelOpenAIResponses(idgpt-5.5), user_memoryUserMemoryConfig(modeLearningMode.AGENTIC), entity_memoryTrue, ) USER_ID composerexample.com agent Agent( modelOpenAIResponses(idgpt-5.5), dbdb, tools[*learning.get_tools(user_idUSER_ID)], instructions[ You are a research assistant., learning.instructions(), ], user_idUSER_ID, markdownTrue, ) if __name__ __main__: agent.print_response( Remember that I prefer sources with primary data, and track the Meridian project - Priya runs it., streamTrue, ) print(\n--- what the manual door placed (guidance data) ---) print(learning.instructions()[:400]) print(...) print(learning.build_context(user_idUSER_ID, messagewhat about meridian?))注意几点没有learning就没有自动捕获Agent 捕获记忆的唯一途径是调用你通过get_tools()交给它的工具。这就是 README 强调的手工之门天生具备 agentic 属性——学习动作由 Agent 自主决定何时调用。实体记忆默认 AGENTIC 模式见 machine.py 的默认配置构造这与session_context文档自称 ALWAYS-only 形成对照。代码末尾直接打印instructions()与build_context()把门上放了两块什么直观展示出来。根据 TEST_LOG.md 的记录在修复缺失model的问题后本示例运行结果是 PASS无learning时手工放置的工具成功捕获了用户偏好用户记忆与 Meridian 项目 Priya 关联实体记忆打印的手工之门表面显示出指导块以及一个数据块——对消息 what about meridian? 的召回将 Meridian 连同 runs - Priya 的一跳边一起带出。实战二with_filesystem.py —— 与 FileSystem 的刻意顺序with_filesystem.py 展示了手工之门的核心价值LearningMachine、FileSystem 与自定义 system prompt 以可以在页面上直接读出来的顺序组合learning LearningMachine( dbdb, modelOpenAIResponses(idgpt-5.5), # the manual door injects nothing user_memoryUserMemoryConfig(modeLearningMode.AGENTIC), ) fs FileSystem(db, namespacecomposition-notes) USER_ID composerexample.com agent Agent( modelOpenAIResponses(idgpt-5.5), dbdb, tools[*learning.get_tools(user_idUSER_ID), fs.tools()], instructions[ You are a research assistant. Keep running notes on topics you research., learning.instructions(), fs.instructions(), ], user_idUSER_ID, markdownTrue, )这是一个精心安排的顺序学习工具 文件系统工具 两段指令块。Agent 收到记录向量数据库对比周五截止的请求后既会写笔记文件FileSystem也会把每个总结中结论优先的偏好写进用户记忆。TEST_LOG 补充了一个非常值得注意的模型行为观察Agent 在把偏好写进笔记的同时也把结论优先这一偏好本身写进了笔记——一主张一归属one-claim-one-home的纪律正是 second-brain 指令在 FileSystem 之上叠加出来的效果。也就是说指令块不只是摆设它确实在改变 Agent 的落盘行为。实战三context_block.py —— 只要数据块不要工具context_block.py 演示第三个表面单独使用只注入build_context()返回的数据块不注入任何工具得到一个对机器所知内容的只读视图learning LearningMachine( dbdb, modelOpenAIResponses(idgpt-5.5), # the manual door injects nothing user_memoryUserMemoryConfig(modeLearningMode.AGENTIC), ) USER_ID composerexample.com # Seed a memory through the data API so the read-only agent has something to see store learning.user_memory_store store.get_tools(user_idUSER_ID)0 # No learning, no tools: just the data block, placed as additional context agent Agent( modelOpenAIResponses(idgpt-5.5), dbdb, additional_contextlearning.build_context(user_idUSER_ID), user_idUSER_ID, markdownTrue, )要点通过learning.user_memory_store拿到 store再直接调用其工具完成一次播种seed让只读 Agent 有数据可看。Agent 不配置learning、不配置tools仅把数据块放进additional_context。TEST_LOG 对此模式的结论是数据块能提供信息但不能强迫模型——重跑验证中播种成功落地后模型依然先列要点、后给结论说明纯数据块只提供信息而不强制结论这一原始观察在修正后依然成立。实战四always_capture.py —— 手工之门上的 ALWAYS 逃生舱always_capture.py 解决一个矛盾手工之门默认没有自动后处理提取捕获全靠工具但如果你既要手工放置的提示词、又要 ALWAYS 模式的后台提取呢答案是capture_hook()learning LearningMachine( dbdb, modelOpenAIResponses(idgpt-5.5), user_profileTrue, user_memoryTrue ) USER_ID composerexample.com agent Agent( modelOpenAIResponses(idgpt-5.5), dbdb, instructions[You are a helpful assistant.], post_hooks[learning.capture_hook()], user_idUSER_ID, markdownTrue, ) if __name__ __main__: agent.print_response( Im Dana, a data engineer in Lisbon. I mostly work on our ClickHouse pipelines., streamTrue, ) time.sleep(10) print(\n--- what ALWAYS capture extracted ---) learning.user_profile_store.print(user_idUSER_ID) learning.user_memory_store.print(user_idUSER_ID)capture_hook()源码见 machine.py返回一个兼容post_hooks的可调用对象内部包裹机器的捕获流程若有background_executor则提交到后台执行器与learning相同的运行位置不阻塞响应路径否则内联执行同步、异步运行都适用。异步场景另有acapture_hook()machine.py把aprocess作为 fire-and-forget 任务调度失败只记日志、绝不抛进运行过程。TEST_LOG 的验证结果是 PASSpost_hooks[learning.capture_hook()]触发了 ALWAYS 提取没有发生任何工具调用就出现了画像Name/Preferred Name: Dana和一条记忆数据工程师、里斯本、ClickHouse 管道。README 明确评价这是逃生舱而非第三种形态——它不是与自动、手工并列的新方式而是在手工之门上补回 ALWAYS 提取的手段。一个反复踩过的坑手工之门不注入任何东西model必须显式给出这是整个11_composition目录的 TEST_LOG 中反复出现、并最终形成工程改进的核心教训。现象模型缺失导致静默失败手工之门不注入任何东西意味着机器上持有的是构造它时给定的db与model。而每一条捕获路径本质上都是一次模型调用update_profile、update_user_memory在无模型时返回 No model providedcapture_hook()的 ALWAYS 提取在无模型时什么都不存实体记忆在无模型时保留每一个陈述过的事实而不会淘汰它矛盾的那些。TEST_LOG 记录了两次重要的 2026-07-26 修正恰恰证明了这种静默失败的隐蔽性basic.py首份日志对用户记忆的判断是错的。机器未带modelupdate_user_memory返回 No model provided什么都没存——只有实体写入无需模型落地了。补上model重跑后update_user_memory才存下 Prefers sources with primary data并在 learnings 表中得到验证。with_filesystem.py同样缺model笔记写入了但偏好没有存储。补上后update_user_memory与append_file双双触发。context_block.py此前把播种的上下文里明明有记忆总结却把结论放最后解读为模型失败实际是存储失败——播种调用也需要模型导致什么都没播进去、上下文块是空的。补上model后种子落地。always_capture.py首跑因空存储而 FAIL——手工之门不注入机器必须显式传model该文件与 README 现在已写明这一点。工程改进attach 时就警告always_capture.py是当时唯一学乖了的文件而LearningMachine.get_tools()现在会在某个需要通过模型捕获的 store 没有模型时警告一次_warn_if_model_missing()见 machine.py列出无法捕获的 store提示工具会返回 No model provided、实体记忆会保留全部事实而不淘汰矛盾项并给出两条出路——给LearningMachine显式传model或改用learning让机器复用 Agent 的模型。这样下一个人是在挂载attach时发现问题而不是等到查空表才发现。别混用两扇门双份渲染警告README 与源码都明确了一条边界同一个机器既传给learning又手工放置它的表面会让指令块和数据块渲染两遍。instructions()调用时会把机器标记为手工放置_placed_by_hand True见 machine.py若框架随后又通过自动注入路径拉取指令_framework_instructions()会检测到该标记并警告一次双份渲染machine.py提示二选一传learning走自动路径或自己放置表面且不传learning。运行方式与环境前提各示例文件头部均给出运行命令例如.venvs/demo/bin/python cookbook/08_learning/11_composition/basic.py四个文件的运行命令依次为basic.py、with_filesystem.py、context_block.py、always_capture.py路径同上。前提条件需要一个可用的 Postgres 数据库示例默认postgresqlpsycopg://ai:ailocalhost:5532/aiTEST_LOG 记录为 pgvector 容器跑在 5532 端口学习存储均持久化于该库。需要可访问的 OpenAI 兼容模型示例用gpt-5.5的OpenAIResponses。根据 TEST_LOG测试针对 gpt-5.5OpenAIResponses在分支feat/entity-memory-revamp上完成2026-07-26 在修复缺失模型问题后复测四个示例全部 PASS。小结手工之门的使用决策场景选择想省事接受框架固定注入位置learning自动之门要把学习、文件系统、自定义提示词按明确顺序组合手工之门 三表面手放只要召回数据、不要捕获工具只读仅build_context()放入additional_context手工提示词 ALWAYS 后台提取post_hooks[learning.capture_hook()]无论走哪扇门请记住手工之门的铁律它不注入任何东西——db与model必须显式交给机器否则捕获会静默失败同一机器不要同时走两扇门否则内容渲染双份。理解了这两条你就能像 FileSystem 那样把学习能力精确地编排进任何 Agent。【免费下载链接】agnoBuild, run, and manage agent platforms.项目地址: https://gitcode.com/GitHub_Trending/ag/agno创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考