我的智能体设计哲学 —— 让 AI 真正干活的工程法则 ## 一、开篇智能体的灵魂是什么2024 年以来几乎每个月都有新的 AI 智能体框架冒出来。每个人都在说我的智能体如何如何但很少有人认真思考一个问题**智能体和聊天机器人到底有什么区别**聊天机器人是一问一答你问它答它说完就结束。但智能体不同。一个真正的智能体核心能力是**自主完成多步骤任务**——它要自己规划、自己行动、自己观察结果、自己决定下一步做什么而不是等着人类每一步都告诉它该干嘛。我花了三个多月的时间从零构建了一个叫 **Agentkit** 的智能体框架。它不是那种塞满炫技功能的玩具而是一套经过真实业务检验的工程实践。这篇文章就是想把这些设计思路说清楚让不懂技术的普通读者也能理解**一个靠谱的智能体到底是怎么被设计出来的**。---## 二、奥卡姆剃刀最好的功能就是没有功能我的哲学第一条来自一把 14 世纪的剃刀。奥卡姆的威廉说如无必要勿增实体。翻译成大白话就是——**不要把简单的事情搞复杂**。很多智能体框架的通病是什么都想做。你可以在 system prompt 里塞五十条指令给它注册一百个工具它看起来无所不能实际上什么都干不好。就像一个人身上装了二十把瑞士军刀最后连拧螺丝都找不对工具。Agentkit 的设计原则非常明确- **不做不存在的功能。** 用户没说要的就不做。不要为了以后可能有用去提前堆砌抽象层。- **不做无用的抽象。** 一个工具函数就是一段代码不需要经过三层工厂模式才能调用。- **能复用就复用。** 写代码最忌讳的事情之一就是重复造轮子——同样的工具调用逻辑不要在三个地方各写一遍。打个比方造一辆车车轮就是圆的没必要把它设计成八边形再通过算法转成圆形。**框架的核心价值是解决问题不是展示你有多会设计模式。**---## 三、循环工程智能体是跑出来的不是想出来的很多人对智能体的理解还停留在我给它一段指令它输出一段结果。但这本质上跟普通的大模型对话没有区别。真正让智能体变得智能的是一个叫做 **循环** 的东西。Agentkit 提出了一个 **六相循环** 模型每一步都不复杂但组合起来就很强大1. **输入捕获** —— 接收用户的需求2. **上下文组装** —— 把历史对话、工具结果、规划信息拼成一个简报3. **模型推理** —— LLM 根据简报决定下一步做什么4. **动作执行** —— 调用工具如搜索网页、查询数据库5. **观测校验** —— 看工具返回的结果是不是够用了6. **记忆更新** —— 把本轮结果写回状态为下一轮做准备你发现没有这其实跟人类做事的逻辑一模一样。你要完成一件事先看看自己有什么信息上下文想一下该做什么推理动手干动作看看效果观测记下来记忆不行就再来一轮。传统做法的误区是**把所有的指令全部塞进 system prompt 里。** 那就像考试前通宵背书考场上全忘了。Agentkit 的做法恰恰相反**system prompt 越短越好只放循环契约——告诉智能体你该用什么方式工作。** 真正的任务目标、规划步骤、工具观测结果都在每一轮动态组装进 user message 里。这就像一个人带队干活你不必在早上就把全天的每一句话都交代清楚而是在每个阶段告诉他目前的情况是这样你接下来做这件事。---## 四、工具是肌肉智能体用它来动手如果你把 LLM 比作大脑那么工具Tool就是它的手和脚。没有工具的智能体只能纸上谈兵。Agentkit 的工具系统有几个关键设计**第一每个工具的结果都要压缩。** LLM 的上下文窗口是有限的。有些工具比如网页搜索返回的结果可能有一本书那么厚。如果不加处理直接扔给模型大脑很快就塞满了。所以我们会对工具结果做精加工summary 关键数据 计数把几万字的原始输出压缩成几百字的重点摘要。这就像秘书在老板开会前先准备好一页纸的简报而不是把原始文件全部摊在他桌上。**第二相同的工具调用不做第二次。** 你有没有遇到过这种情况问智能体一个问题它明明已经查过数据库了过了一会儿又问了一遍同样的问题这不是它笨而是它忘了自己做过什么。Agentkit 用了一个叫 **工具指纹** 的技术。每次调用工具我们都会根据工具名 参数生成一个唯一的 SHA256 指纹。下一次如果遇到完全相同的调用直接从缓存里取结果不走第二遍。这既省了时间也省了钱API 调用是要花钱的。**第三工具系统是轻量级的。** Agentkit 的 MCPModel Context Protocol客户端只有不到 200 行代码。它不做复杂的会话管理不做花哨的负载均衡就做一件事连上外部工具服务器调用工具返回结果。---## 五、四个基础概念为什么缺一不可在 Agentkit 里所有的智能体能力都建立在四个基础概念之上**工具Tool**、**技能Skill**、**子智能体Sub-agent** 和**专精智能体Specialist Agent**。它们不是随便分出来的而是每一层解决一个特定的问题。少了任何一个系统的能力就会出现断层。我们一个一个来看。### 1. 工具Tool—— 智能体的手和脚工具是最小单位的可执行动作。一个工具就是输入参数 → 执行动作 → 返回结果这么一个简单的闭环。比如- web_search(北京天气) → 返回搜索结果- db_query(SELECT * FROM orders) → 返回数据库记录- send_email(to, subject, body) → 发送一封邮件**为什么不能没有工具** 因为 LLM 本身是只说不做的。它再聪明也发不了邮件、查不了数据库、访问不了网页。工具就是给 LLM 安装的外挂器官——没有它智能体只能侃侃而谈什么实事都干不了。但工具也有它的局限它**太细了**。一个工具就是一步操作。如果要完成帮我在知识库里检索资料然后用检索结果写一份报告最后发到群里这样的事情光靠单个工具是搞不定的——你需要把多个工具串起来。这就是 Skill 出场的原因。### 2. 技能Skill—— 可复用的肌肉记忆如果说 Tool 是单一动作那 Skill 就是**一套编排好的动作组合**再加上元数据什么时候该用、什么时候不该用、输出什么格式。举个例子你有一个 search_knowledge_base 工具和一个 generate_report 工具。单独看它们各管各的。但把它们组合成一个叫 knowledge_report 的 Skill智能体就知道当用户让我调研某个话题并出报告时我应该先用检索工具找材料再用生成工具写报告。**为什么不能没有 Skill** 因为 LLM 没有肌肉记忆。每次遇到同一类任务它都要从头推理一遍该调用哪个工具、按什么顺序。这不仅慢、费钱还容易出错。Skill 就是把这些已验证有效的执行路径固化下来像人类的肌肉记忆一样——下次遇到同样的情况不用过脑子直接上手干。而且 Skill 还有一个更厉害的能力**可以在运行时动态创建**。什么意思如果一个智能体反复做不好某类任务调度会触发技能开发流程——先调研问题的本质然后编写一个 Skill 脚本并注册到系统中。下次遇到同样的问题直接调用这个新 Skill 就行不用再让 LLM 从零推理。这是 Agentkit 的**自进化能力**。Skill 的注册表就是一个技能目录里面既有系统内置的技能builtin也有用户上传或智能体自己开发出来的技能developed/uploaded还有通过 MCP 协议接入的外部技能。每个技能都有自己的名字、描述、适用场景和反适用场景智能体可以根据任务描述自动选择匹配的 Skill。 打个比方**Tool 是乐高积木的单个颗粒Skill 是用这些颗粒搭好的一个模型。** 你不需要每次搭房子都从找颗粒开始——直接从房子模型起步就行。### 3. 子智能体Sub-agent—— 派出去的侦察兵子智能体是 Agentkit 里最有意思的设计之一。它本质上是一个**临时创建、独立运行、用完即走**的迷你智能体。**它是怎么工作的** 父智能体通常是调度器给子智能体一个明确的子任务然后它带着这个任务和一套受限的工具集进入一个隔离沙箱开始工作。它有自己的消息循环、自己的上下文窗口跟父智能体互不干扰。工作完成后它把结果浓缩成一段摘要汇报给父智能体然后自己就消失了。**为什么不能没有子智能体** 原因有三第一是**隔离**。假设你让一个智能体同时查北京、上海、深圳三个城市的政策。如果让它在同一个上下文里做三个城市的信息会搅在一起——它可能把北京的结论和深圳的搞混。但如果派三个子智能体各自查一个城市它们互不干扰最后把三份干净的摘要合并在一起。第二是**并行**。三个子智能体可以同时跑互不等待。对于多路调研这种任务速度是串行的三倍。第三是**预算控制**。每个子智能体在自己的上下文窗口里工作它的全部产出被压缩成一小段摘要后才回传给父智能体。这就好比一个将军派出三个侦察兵去三个方向侦察侦察兵回来后各交一份简报将军不需要阅读他们写满原始记录的笔记本。 注意**子智能体和专精智能体虽然听起来像是一回事但它们要解决的问题完全不同。** 子智能体解决的是拆任务的问题——它是临时的、轻量的、用完即焚的。而专精智能体解决的是分专业的问题——它是常设的、有固定角色的、维护着长期知识和工具的。下面展开说。### 4. 专精智能体Specialist Agent—— 各司其职的部门经理一个智能体不可能什么都会。如果你让同一个智能体既做财务分析、又写营销文案、又调试代码它在每个领域都只能是半桶水。专精智能体的思路很简单**为不同的领域配备不同的智能体每个只做自己最擅长的事。**在 Agentkit 里有一个**调度智能体Orchestrator** 负责理解用户需求然后通过路由系统把任务分发给合适的专精智能体。目前系统中常见的专精角色包括- **research** —— 资料检索、知识问答、联网调研- **platform** —— 文档管理、用户管理、系统配置- **report** —— 长文档撰写、研究报告生成- **diagram** —— 流程图、思维导图等图示绘制- **rpa** —— 浏览器自动化、网页操作- **scheduler** —— 定时任务、到期提醒- **skill-dev** —— 技能开发为系统编写新的 Skill每个专精智能体都有自己的 system prompt角色说明书、工具集、和知识边界。调度器在做路由决策时会考虑这个任务需要什么能力→哪个专精智能体匹配这个能力→以什么模式执行串行/并行。**为什么不能没有专精智能体** 因为没有分工就没有效率。一个什么都能干的通用智能体在每一个细分领域都会被专精智能体完爆。而且从工程维护角度看每个专精智能体的行为可以独立调优——修改 research 的 prompt 不会影响 report 的行为反过来也一样。万一某个专精智能体出了 bug不影响其他领域正常运作。**最后用一个真实流程把这四个概念串起来理解** 用户说帮我调研一下最近 AI 编程工具的趋势写一份报告然后发到群里。 1. 调度器Orchestrator先分析需求拆出两个子任务①调研趋势 ②写报告 2. 它派一个**子智能体**去执行调研这个子智能体在隔离环境里调用 web_search **工具**上网搜索收集信息 3. 子智能体返回一份摘要调度器把摘要转交给 **report 专精智能体** 4. report 专精智能体调用一个叫 trend_report 的 **Skill**这个 Skill 知道报告该用什么结构、什么语气、什么长度自动生成报告 5. 最后调度器调用 send_message 工具把报告发到群里你看**工具**负责动手、**技能**固化经验、**子智能体**隔离并行、**专精智能体**聚焦领域。缺了任何一个这个流程要么跑不动要么跑不好要么跑不快。---## 六、路由与编排让专业的人做专业的事上一节已经详细解释了四个概念及其关系这一节聚焦它们是怎么被串起来的。Agentkit 采用了一种叫做 **星型编排** 的架构。核心思想是有一个**调度智能体**Orchestrator负责理解用户需求然后把它拆成子任务分发给**专精智能体**去执行。有点像一个大厨调度接到订单一桌菜他不会自己去切所有的菜而是告诉配菜师傅专精 A、面点师傅专精 B、烧烤师傅专精 C各自干什么最后把所有人做好的东西拼成一桌菜。这里面有三个关键模式- **串行** —— 任务有明确的先后顺序。比如先搜索资料再写报告。前面的步骤是后面的前提。- **并行** —— 任务之间互不依赖。比如同时查三个不同网站的资料同时跑最后汇总。- **协助Assist** —— 一个专精智能体干到一半发现需要另一个领域的知识主动请求调度安排外援。这就像财务做报表时发现需要了解某个业务部门的流程就请业务同事来帮忙。还有一个很重要的设计叫 **能力升级** 。如果一个专精智能体反复做不好某件事调度不会一直让它重试而是会触发技能开发流程——先调研再写一个可复用的 Skill 固化下来。下次遇到同样的问题直接调用脚本就行了不用再让 LLM 从头推理。---## 七、预算意识智能体的能量守恒这是几乎所有智能体框架都忽视的问题但在我看来可能是最重要的。LLM 的上下文窗口是有上限的API 调用是按 token 算钱的。如果你不控制开销一个稍微复杂一点的任务就能花掉几十美元。Agentkit 把预算控制作为一等设计原则。体现在几个方面- **历史裁剪** —— 对话长了不是全留着而是从最近的开始保留同时约束条数和字符数。旧的聊天记录会被遗忘。- **工具压缩** —— 超大的工具输出会被自动压缩图片二进制数据会被直接丢弃只保留摘要。- **路由上限** —— 一个任务最多串行 3 次 handoff并行最多 2 个智能体同时跑。不是不能更多而是不值得——边际效益递减。- **上下文预算** —— 每条消息的字符数、每个检索块的大小都有上限超过就截断。听上去好像有点抠门但这就是工程思维的体现**资源是有限的好的设计不是能处理无限资源的情况而是在有限资源下做到最好。**---## 八、人机协作智能体知道什么时候该问人我见过很多智能体设计它们最大的毛病是**自作主张**。用户说帮我处理一下这些文档好家伙它二话不说就把一百份文档全删了。你说它错了吧它确实理解了用户的指令你说它对了吧用户根本没让它删。Agentkit 引入了 **HITLHuman-in-the-Loop人在回路** 机制。核心是响应盒模式1. 智能体遇到需要人类确认的事情比如真的要删除这些文档吗2. 它会创建一个请求盒放入问题 选项3. 前端展示给用户4. 用户选择确认或拒绝5. 智能体读取结果后继续执行这个机制看起来很简单但它解决了一个根本性的信任问题**用户不需要时刻盯着智能体但关键环节必须由人拍板。**这种设计在心理学上也很重要。人对 AI 最大的恐惧就是失控。一个懂得在关键时刻停下来请示人类的智能体比一个什么都能做但从不打招呼的智能体让人安心得多。---## 九、上下文管理智能体的记忆法前面提到过智能体不能什么都记。但同样糟糕的是它也不能什么都忘。一个好的上下文管理策略应该像人脑一样分层次- **短期记忆** —— 本轮对话的内容。比如正在执行的任务、刚调用的工具结果。这些会保留完整信息。- **中期记忆** —— 前几轮对话的简报。不保留原文只保留要点。类似于人类对几天前聊过的事情能回忆起大概是聊了什么但记不住每一句话。- **长期记忆** —— 从经验中提炼的结论。比如之前调研过的某个网站的结构、某个常用的数据库查询模板。这些会被写成 Skill 固化下来。Agentkit 还有一个非常有特色的设计叫 **追问检测** 。用户说继续、然后呢、另外也查一下这些不是全新的独立问题而是对前文的跟进。系统会识别出这些跟帖把它们和前面的对话关联起来处理而不是当成一个全新的对话轮次。这听起来很自然对吧但很多 AI 产品其实做不到这一点——你刚问完北京有什么好玩的说了一句还有呢它可能就忘了上一个话题开始答非所问。---## 十、结语智能体不是魔法是工程写完这些我想说一句可能不太讨喜的话**智能体不是靠大模型涌现出来的而是靠工程一点点搭起来的。**很多人以为有了 GPT-4 这样的强大模型智能体就是往里面加 prompt 就行。这种想法就像以为有了最好的发动机就能直接开上马路一样天真。一辆好车需要发动机但还需要轮胎、方向盘、刹车、安全带、仪表盘、悬挂系统……每一个部件都不起眼但少了任何一个车都开不远。Agentkit 的设计哲学归结起来就是下面这 10 条1. **别做多余的事** —— 奥卡姆剃刀不加不必要的功能2. **让它跑起来** —— 循环工程智能体是在迭代中变聪明的3. **给它好用的工具** —— 但要压缩结果、避免重复调用4. **把经验固化下来** —— Skill 让已验证的执行路径可复用5. **隔离并行用完即焚** —— 子智能体解决多路探索问题6. **让专业的人做专业的事** —— 专精智能体各司其职7. **分而治之** —— 路由与编排把复杂任务拆解成可管理的单元8. **控制预算** —— 好的设计知道资源有限9. **关键时刻问人** —— 不要让智能体自作主张10. **学会记和忘** —— 上下文管理是智能体的记忆术没有一条是高深的理论每一条都是我在实际编码和调试中踩过的坑。把这些坑填平了智能体才能真正帮你干活。