TL;DR用企微|钉钉 WebSocket Claude Agent SDK 搭了个内部智能助手靠滚动摘要窗口解决上下文断裂、进程池解决冷启动、热插拔工具系统实现低成本扩展。Non-goals 比功能列表更值钱。上线后研发被打断次数下降 75%工单响应从 15 分钟缩到 3 分钟。这不是一篇如何用 AI 改变世界的宏大叙事是一个部门级内部工具的真实落地记录——从被杂活淹没到机器人接手 60% 对外咨询踩过的坑、做的取舍、最后跑通的那套架构。为什么我们要造这个东西先说痛点。我们部门对外的日常事务大致是这些技服每天回复工单——客户报 502要查日志、查工单、查版本、给排查结论其他部门来问知识库——“支付模块回调怎么设计的”“怎么申请服务器权限”项目经理想知道进度——这周 sprint 推到哪了最近提交了什么构建失败要通知——Jenkins 挂了谁在盯这些活单个不难但架不住量大、重复、碎片化。一个研发一天被打断 5 次回答怎么查日志正经活就别干了。所以目标很明确造一个内部智能助手把这些重复性对外咨询接过来 60%-70%让研发测试产品能专心做自己的事。产品思路少做比多做重要内部工具最大的陷阱不是功能不够是什么都想做。我们花了大量时间定义不做什么。Non-goals 清单——这条最值钱不做理由不对外部客户内部工具信任容忍度高外部客户要求完全不一样不做代码自动修复只查日志给结论不改代码——边界要清晰不做知识库自动生成FAQ 人工维护不让 AI 自己创造知识不做多语言中文够了不做自动操作生产环境Jenkins 触发、Git 操作必须人工确认成功指标——怎么知道真的省了 60% 的活替代 60%-70% 杂活是愿景不可衡量就是耍流氓。我们定了两个指标简单粗暴指标定义目标机器人接手率机器人独立解决的问题数 / 总咨询数≥50%回答可用率用户未在同一会话内追问同一问题的比例≥70%测的方式也很轻——服务日志里给每条会话打个标resolved_by_bot/escalated_to_human/user_reasked。不需要数据平台grep一下就出来了。安全边界——机器人不能碰的红线这条是产品审核时被拍桌子补上的。工具都给齐了Jenkins、JIRA、Git不划清边界等于没安全。禁止机器人自动执行 - 生产环境变更重启服务、修改配置、切换流量 - 数据库写操作UPDATE / DELETE / INSERT - 客户数据修改退款、订单变更、账户操作 - 敏感信息返回密码、密钥、Token、手机号明文还有一条兜底规则连续 2 轮回答不确定时自动附加⚠️ 以上分析供参考建议人工核实。内部工具最大的信任危机不是功能少是瞎说还不认。整体架构先看全景再拆开讲。WebSocket 长连接需要压缩不需要响应WebSocket 推送企微群/私聊 机器人本地服务 Python会话管理器权限管理器推送管理器滚动摘要判断Haiku 压缩历史直接处理Agent SDK Sonnet 4.6工具层 热插拔wikijiraoss_logsgit_reposjenkins...更多工具记忆系统MEMORY.md 索引facts/ 明细本地向量库FAQ 知识库整个链路是企微消息 → WebSocket → 本地服务 → Agent SDKSonnet 4.6→ 调工具 → 回企微。所有东西跑在本机内网不依赖外部 APIembedding 用的也是本地模型。核心技术决策决策一Agent SDK 而不是 CLI 外挂最早的版本是把 Claude Code CLI 当黑盒用——stdin 喂 promptstdout 读结果。能用但有个致命问题上下文是 CLI 的私有状态你改不了。后来迁到 Agent SDK整个世界清爽了。上下文变成了你可以程序化读写的对象# 伪代码示意classRollingContextManager:defbefore_turn(self,agent,session):ifsession.should_compress():old_msgssession.get_messages()[:-5]summarycheap_llm.summarize(old_msgs)session.replace_messages([SystemMessage(summary),*session.get_messages()[-5:]])不用杀进程不用 stdin/stdout 拼接直接替换消息历史。这一步迁移是整个架构最重要的一次升级。决策二滚动摘要窗口——解决上下文断裂这是整个项目最痛的一个问题。工单场景经常这样技服 机器人查一个 502从查 JIRA → 查日志 → 分析 → 追问 → 再查别的日志一来一回 30 多轮上下文就爆了180k tokens 硬上限。一旦爆了机器人失忆前面排查到哪一步全忘——技服同事当场就弃用了。试过三个方案方案思路问题会话快照爆了才压缩存个摘要用户能感知到断了工单锚点结构化存工单状态工具不触发就漏滚动摘要主动压缩永不让它爆选这个滚动摘要的核心思路不等它爆到了水位就压。120k tokens25 轮距上次压缩 5 轮都不满足新消息到达触发判断压缩直接处理保留最近 5 轮原文其余历史 → Haiku 压缩拼装: 摘要 5 轮原文替换 Agent 上下文继续对话三个触发条件满足任意一个就压水位触发上下文逼近 120k tokens留 60k 缓冲轮次触发对话超过 25 轮频率保护距上次压缩至少隔 5 轮避免震荡压缩逻辑极简保留最近 5 轮原文其余全部丢给 Haiku 压成 ≤500 字摘要。prompt 就一句话“把以下对话压缩成不超过 500 字的摘要保留关键决策、排查步骤、未解决问题。”用户侧完全无感——他不会知道中间压了一次对话照样连贯。这是整个项目最值钱的一个设计。决策三进程池预初始化冷启动是延迟大头——加载模型、初始化工具、读权限配置一次就要好几秒。对内部工具来说每次 机器人等 5 秒才出字体验就崩了。解法很直白预启动一批 Agent 实例放池子里。进程池: ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Agent-1 │ │ Agent-2 │ │ Agent-3 │ │ Agent-4 │ │ (闲置) │ │ (使用中) │ │ (闲置) │ │ (闲置) │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ 会话到达 → 取闲置实例 → 注入上下文 → 执行 → 归还 心跳 30s挂了的自动补默认 4 个实例配置可改。实测 10 个并发会话完全扛得住首字响应中位数 3 秒。决策四工具热插拔——skill.md tool.py每个工具就是一个目录里面两个文件tools/ ├── wiki/ │ ├── skill.md # 工具描述喂给 Agent │ └── tool.py # 实际执行逻辑 ├── jira/ │ ├── skill.md │ └── tool.py └── ...skill.md告诉 Agent 这个工具能干什么、怎么调。tool.py暴露统一接口asyncdefrun(params:dict,context:ToolContext)-ToolResult:每个工具暴露唯一的 run 函数...服务启动时扫一遍tools/目录自动注册。新增工具就是加个目录然后重启核心代码一行不用改。这个设计让我们加工具的成本极低一周加了 4 个新工具都是顺手的事。决策五权限按群和用户双重控制内部工具必须管权限——技服能查客户信息研发不能研发能触发 Jenkins技服不能。用 YAML 配简单明了# 角色 → 工具basic:[wiki,knowledge_base,version_query]# 全员support:[customer_query,oss_logs,jira]# 技服devops:[git_repos,jenkins]# 研发# 用户 → 角色zhangsan:[basic,support]lisi:[basic,devops]# 群 → 角色技服群:[support]研发群:[devops]全员群:[basic]校验在工具调用前完成无权限直接返回提示。用户级和群级双重校验——在研发群里机器人即便你是技服也只能用研发工具。这个设计防止了在错的地方调错的工具。记忆系统简单够用就行没上向量数据库存记忆就是文件系统memory/ ├── MEMORY.md # 索引 ├── facts/ # 明细 │ ├── 2026-07-08.md │ └── ...MEMORY.md 长这样# 机器人记忆索引 ## 工单 - TKT-0712: XX公司 支付502 → 后端OOM已重启 ## FAQ被问 ≥3 次自动收录 - 支付回调失败怎么排查→ 查nginx → 回调服务 → 支付网关 ## 版本 - v3.2.1: 2026-07-05 发布修复 OOM规则也简单同一问题被问≥3 次→ 自动写入 MEMORY.md每天凌晨梳理一次合并同类项15 天没被引用的记忆标记 pending_delete再等 3 天还不引用就物理删不上数据库的理由内部工具记忆量不大文件系统 grep 一下比查数据库还快。等真撑不住了再迁不迟。踩过的坑坑一上下文断裂是信任杀手前面说过工单多轮追问爆 180k 后机器人失忆。这个问题坑了我们好几天——技服同事第一反应是这玩意不靠谱直接不用了。教训内部工具可以容忍功能少不能容忍突然变笨。滚动摘要窗口上线后断裂问题消失信任才回来。坑二CLI 外挂做不了上下文管理最早用 CLI stdin/stdout想做滚动摘要得杀进程重启极其难看。迁到 Agent SDK 后上下文变成可操作的对象问题自然没了。教训选 AI 框架时先想清楚你要多大控制权。如果你只是问答CLI 够了如果你要做上下文管理、工具编排、会话隔离老老实实用 SDK。坑三不加兜底提示出错没人兜有一次机器人把日志分析错了技服拿着错误结论回了客户差点出事。后来加了连续 2 轮不确定就提示人工核实的规则。教训AI 给的结论内部场景也要标仅供参考。尤其是会影响对外决策的工单回复、进度汇报必须有兜底提示。跑起来之后目前运行良好上线前后的对比数据指标上线前上线后变化研发日均被打断次数5-8 次1-2 次↓ 75%工单平均响应时间15 分钟3 分钟↓ 80%FAQ 咨询人工介入率100%30%↓ 70%研发连续专注时长 1 小时2 小时↑ 100%首字响应延迟— 3 秒中位数—并发会话数—10 个无压力—已接入工具数08 个持续增加—以上数据为部门内部统计不同团队规模和场景会有差异。使用场景覆盖技服工单排查、知识库咨询、项目进度查询、构建失败推送、健康提醒。最直观的感受研发被打断的次数明显少了。以前一天被 5 次回答怎么查日志现在机器人接了研发能连续写两小时代码不被打断——这才是我们想要的。一些反思回头看有几个决策做对了Non-goals 先写——防止范围蔓延这是内部工具存活的关键滚动摘要优先级最高——上下文断裂是信任杀手必须先解决Agent SDK 而不是 CLI——控制权决定了你能做多少事工具热插拔——加工具成本极低迭代速度快安全边界明确——不碰生产、不碰数据库写、不碰客户数据也有做得不够的FAQ 知识库一开始想上向量检索后来发现关键词匹配就够用白纠结了一周。教训先跑起来再优化别一上来就过度设计记忆系统还没上自动梳理目前人工维护量大了会成负担下一步计划上向量检索升级 FAQ 精度把记忆系统的自动梳理补上再扩展几个推送场景代码走查严重问题、发布通知。如果你也在考虑给团队搭一个内部 AI 助手我的建议是先想清楚不做什么再想做什么。功能可以慢慢加边界一旦模糊了收不回来。