在企业内部信息检索的体验常常令人抓狂。研发团队想知道某个服务的部署步骤得翻遍 Confluence 里过时的文档新员工想搞懂报销流程要在一堆 PDF 和共享文件夹中来回横跳。传统的做法通常是两种要么靠人力维护一个 FAQ 机器人要么用 RAG 搭一个内部问答系统。但前者维护成本高得吓人后者在面对“去 xxx 页面里把那几行配置找出来”这种精确指令时又显得笨拙不堪。有没有一种方式既能像 RAG 那样快速覆盖海量非结构化知识又能像资深员工一样灵活地、精准地找到角落里的一条具体记录最近一些团队开始尝试用Claude Code SDK来撬动这个难题结果出人意料地顺手。这篇文章就来复盘一下如何在企业内部基于 Claude Code SDK 和 Wiki 等知识库快速拼装出一个既聪明又务实的问答 Agent。为什么纯 RAG 和纯 Agentic Search 都不够用在动手之前先厘清一个关键认知。Claude Code 本身采用的是一种叫作Agentic Search智能体搜索的机制它不预先为文档建立任何向量索引而是让大模型像人类一样实时地运行grep、读取文件、跳转引用靠一轮轮的现场推理来锁定答案。这套打法在代码库中极为高效因为代码天然具有高度结构化和精确匹配的需求。但如果把同样的机制直接搬到企业的 Wiki 上问题就来了。Wiki 内容本质是自然语言表达方式千奇百怪。问“如何开通邮箱”文档里可能写的是“电子邮件账户创建指南”。纯靠grep关键词很容易漏掉大量相关信息。更重要的是当 Wiki 条目积累到成千上万时每一次提问都去现场搜索、多轮读取无论时间成本还是 Token 消耗都会飞快地突破一个可接受的范围。RAG 恰好相反。它凭借语义向量的模糊匹配可以瞬间从海量文档中捞出一批“意思差不多”的片段。但它天然害怕需要精确查找的场景也很难理解文档之间的引用关系更不会主动去核实某个答案的来源是否已过期。于是务实的选择浮出水面让 RAG 负责“广撒网”的语义初筛让 Agent 负责“精加工”的推理与查找。Claude Code SDK 正是那个能将二者拧成一股绳的胶合剂。整体架构一个会“查字典”的智能侦探打造的这个 Agent可以看作一个升级版的问答引擎。它的工作流大致如下理解意图Claude 模型拿到用户的问题判断这是一个需要语义搜索的开放性问题比如“xx 功能的原理是什么”还是一个需要精确查找的指令比如“找出上季度安全审计报告的第 5 页”。语义召回如果判断为开放性问题Agent 会调用一个专门的工具——search_wiki这个工具背后挂着一个向量数据库里面存放着所有 Wiki 页面和内部文档的嵌入向量。工具瞬间返回 Top-K 个相关片段。精确挖掘与核实Agent 拿到这些片段后可能会进一步调用read_file或grep去原文中核对细节或者顺着文档间的链接跳转到关联页面。如果初次召回的答案模糊它还能自己调整关键词发起新一轮搜索。综合回答最后Agent 将多个来源的碎片信息揉合在一起组织成一个有引用、有上下文的完整答案。这整套逻辑的背后是 Claude Code SDK 提供的“工具调用闭环”。SDK 允许开发者在自己的应用里启动一个拥有文件系统访问、命令行运行能力的智能体并且还能通过MCP模型上下文协议挂载任何自定义的外部工具——比如刚刚提到的向量搜索服务。分步实战从 Wiki 到问答四步搭完下面拆解具体的实现过程。所有代码都以示意图的方式给出真实落地时需要根据团队的技术栈微调。第一步整理知识库生成向量索引假设内部知识散落在 Confluence 空间、Git 仓库的/docs文件夹和一些共享 PDF 里。第一步就是把它们统一捞出来切分成小块并送入向量数据库。这个环节可以直接用市面上成熟的 RAG 框架比如 LangChain 或 LlamaIndex来完成甚至写一个小脚本也绰绰有余。# 用 LlamaIndex 为 Markdown 文档建索引的极简示例fromllama_index.coreimportVectorStoreIndex,SimpleDirectoryReader documentsSimpleDirectoryReader(./wiki_markdown).load_data()indexVectorStoreIndex.from_documents(documents)index.storage_context.persist(persist_dir./wiki_index)这一步完成后团队手里就多了一个“Wiki 语义字典”能够根据自然语言快速找到相关文档片段。第二步搭建 MCP 检索服务器为了让 Claude Code Agent 能用上这个字典需要把它包装成一个符合 MCP 规范的工具。MCP 是 Anthropic 提出的一种通用协议相当于 AI 应用的“USB-C 接口”。通过一个简单的 Python 或 Node.js 服务开发者可以把向量检索封装成一个可供大模型调用的函数。# mcp_server.py (伪代码基于 MCP Python SDK)frommcp.serverimportServer,Toolfromllama_index.coreimportStorageContext,load_index_from_storage serverServer(wiki-search)indexload_index_from_storage(StorageContext.from_defaults(persist_dir./wiki_index))server.tool(search_wiki)asyncdefsearch_wiki(query:str)-str:语义搜索内部 Wiki 文档返回最相关的片段retrieverindex.as_retriever(similarity_top_k5)nodesretriever.retrieve(query)return\n\n.join([n.textforninnodes])server.run()启动这个服务后任何遵循 MCP 的客户端包括 Claude Code都能发现并调用search_wiki这个工具。第三步配置 Claude Code Agent接下来是核心环节告诉 Claude Code 智能体存在这么一个新工具并指导它如何协调使用。如果团队使用的是 Claude Code 的命令行版只需要在配置里添加一行 MCP 服务器的地址即可。// .claude/settings.json{mcpServers:{wiki:{command:python,args:[mcp_server.py],cwd:/path/to/server}}}如果是通过Claude Code SDK编程嵌入到自定义应用中代码会更加灵活。下面是一个基于 Anthropic SDK模拟 Claude Code 风格的 Agent 循环的极简示例importanthropic clientanthropic.Anthropic()tools[{name:search_wiki,description:Semantically search internal Wiki documents.,input_schema:{type:object,properties:{query:{type:string}}}},# 还可以继续添加 read_file, grep 等原生工具]defagent_loop(user_message):messages[{role:user,content:user_message}]whileTrue:responseclient.messages.create(modelclaude-sonnet-4-20250514,messagesmessages,toolstools,max_tokens4096)ifresponse.stop_reasonend_turn:returnresponse.content[0].text# 处理工具调用forblockinresponse.content:ifblock.typetool_use:ifblock.namesearch_wiki:resultcall_mcp_search_wiki(block.input[query])messages.append({role:user,content:[block,{type:tool_result,content:result}]})至此Agent 就具备了“先查语义字典再精细核实”的混合能力。第四步赋予 Agent 一点点“记忆”和权限为了让 Agent 真正好用还有几处细节值得打磨。比如可以给 Agent 添加一个get_current_user工具让它根据角色判断哪些页面有权访问或者加上mark_document_outdated功能当发现某个 Wiki 页面的更新日期超过一年时主动在回答中提醒用户。这些能力只需要在 MCP 服务器里多暴露几个工具接口即可整个框架完全不变。落地时的经验与避坑指南这套方案在几家企业内部落地后积累了一些值得注意的经验索引更新策略比选型重要。Wiki 是活的每时每刻都可能变化。在搭建初期可以采取每晚全量重建索引的方式迭代几版后应当引入基于 Webhook 的增量更新确保 Agent 的回答不会沦为“考古”。明确的工具描述是 Agent 的灵魂。在 MCP 服务器里注册工具时文字描述要极其清晰甚至像“当用户问及 xxx 时应优先调用此工具”这样指导性的语句都能极大提升模型选择正确工具的概率。成本控制靠分层缓存。高频的常见问题不必每次都去求助于大模型。可以在最外层加一个简单的缓存或匹配层对于已经回答过且文档未更新过的提问直接返回缓存结果。这一层甚至可以就用 RAG 本身来做而 Agent 只负责处理复杂或模棱两可的查询。权限与隐私不可忽视。向量索引本身无法理解文档的访问控制列表。解决方法是检索阶段先尽可能多地召回内容但在 Agent 最终输出答案前利用get_user_permissions工具进行一次过滤只允许显示访问者有权查看的信息。结语用 Claude Code SDK 打造企业内部的 Wiki 问答 Agent本质上并不是在创造一套全新的魔法而是在已知的技术组件之间找到一种更符合人类习惯的组合方式。RAG 像是给团队配备了一个过目不忘的图书馆管理员而 Agent 则是一个充满常识、懂得随机应变的业务专家。把两者合二为一带来的直接回报是新人不再需要花三天时间翻阅几十个页面才能拼凑出一个操作步骤研发团队也不再因为找不到某条古老的设计决议而反复踩坑。更妙的是这套架构的扩展性极强。将来把内部的 Jira、代码仓库、甚至 Slack 频道记录也以相同的方式挂载上去这个 Agent 就会从“Wiki 问答员”慢慢成长为真正理解整个组织脉络的数字同事。在那一天到来之前这四步走就是一张清晰且务实的施工图。