#子智能体

4小时前

Skills详解：与提示、项目、MCP和子智能体的对比（A 家虽然魔怔，但博客很不错）😂

Claude Skills系统发布引发AI行业新变革· 48 条信息

#Skills详解 #提示 #项目 #MCP #子智能体

1个月前

如果你在为公司现有业务集成 AI Agent，或者迁移到 AI Agent，我自己的一点思考供参考： 1. 如果你流程的路径很确定并且效率很高，那么也许你只需要在原有流程上集成一些 AI 功能就可以，并不一定要变成 Agent 通常 Agent 没有固定流程，依赖于用户的输入来由 LLM 决策调用什么工具 2. 为 Agent 去重新设计新的工具而不是让 Agent 去用现有的工具通常公司内部已经有一些成熟的工具，但这些工具是为人设计的而不是 Agent 设计的，当你去做 Agent，要重新为 Agent 做新的工具，什么工具是最适合 Agent 就去打造什么工具，但不是因为你有什么工具所以让 Agent 去用什么工具。另外 Agent 的工具要融入上下文管理： - 描述要清晰具体，让 LLM 知道什么场景该使用什么工具 - 输入参数要明确：即让 LLM 知道该传什么参数，又要让工具有足够的数据可以执行 - 输出结果要清晰明了，不要有太多无关上下文内容，因为工具输出的结果会加入 Agent 的上下文，有些很长的输出可以保存到外部文件按需读取 3. 不要为了 MCP 而用 MCP MCP 很流行，但它的优势是让你的工具可以兼容不同的模型，不同的 AI 平台，如果你的工具只有你自己的 Agent 用，没必要做成 MCP，普通的命令行、脚本、API 都可以。你看 Claude Code 的十几个工具没有一个是 MCP。 4. 工具数量不要太多，基于功能可以适当拆分子智能体由于工具的描述、输入和输出都占用上下文空间，所以工具数量不能太大，否则会影响 Agent 的能力。如果你的工具实在太多，可以考虑按照功能拆分成子智能体，让一个子智能体负责某些特定功能的任务，它可以拥有自己的工具集，主 Agent 则负责调度这些子 Agent，为子 Agent 提供独立的上下文，并收集子 Agent 返回的结果。如果子 Agent 或者工具的结果之间有依赖关系，不要并行执行任务，否则会搞乱上下文 5. 需要为 Agent 重新设计交互你的软件也许已经有一套交互方式了，但当你去做 Agent 的时候，要重新思考什么是最佳交互方式。 Agent 的交互和传统的软件交互是不一样的，通常以对话为主，用户可以通过对话框输入文本信息，上传文档、图片等作为上下文一部分，信息则更像聊天对话，实时可以看到 AI 返回文本、工具调用结果等。还可以是有一个主要工作区，类似于传统的软件交互，侧边栏是 Agent 聊天对话。在 Agent 交互方面，ChatGPT、Claude、Cursor、Notion、Gemini 等产品都有很多交互可以参考，多借鉴前沿主流的 Agent 交互方式

#AI Agent #LLM #工具设计 #交互方式 #子智能体

3个月前

这里面很有意思的点是 Agent 1.0 到 Agent 2.0 的升级，其中最大的变化： Agent 1.0 的时候会压缩历史会话，Agent 2.0 就不压缩了，只处理用户输入的大内容。这其实现在也是 Agent 请求的标配，不再花精力去压缩上下文，无脑把历史会话都发过去，一方面这样不担心上下文损耗，一方面 Prompt Caching 可以降低成本。但是对工具的调用仍然会对结果进行总结和记忆，因为工具是相对独立的上下文，只要把关键信息加入主上下文即可。同时工具还可以是子智能体，也可以帮助分担上下文，避免很快上下文就爆掉。

#Agent升级 #上下文处理 #Prompt Caching #工具调用 #子智能体