AI办公技术栈拆解：基于RAG与Agent的智能应用开发实战

阿里、字节、腾讯同时发力AI办公，开发者能抓住哪些机会？

最近一段时间，阿里、字节、腾讯三家几乎同步在AI办公赛道上加码，从在线文档、会议纪要，到企业知识库、AI Agent，动作非常密集。很多读者在后台问：这些看起来很酷的办公功能，背后到底是怎样一套技术栈？作为普通开发者，我们应该从哪个方向切入，才能跟上这波AI应用开发的节奏？

这篇文章不聊商业竞争格局，而是从工程视角拆解AI办公的核心技术模块，包括文档解析、会议转写、知识库问答、智能体协作等。文章会给出完整可运行的示例代码，并梳理常见问题与工程化实践。无论你是准备做个人效率工具，还是给企业做内部AI办公平台，都可以参考这套思路。

1. AI办公的本质：从“工具连接”到“智能协作”

1.1 为什么大厂开始集中发力AI办公

传统办公软件解决的是“流程线上化”问题，比如在线文档解决多人协同编辑，会议软件解决远程沟通，IM解决即时消息传递。但这些工具的本质都是“容器”，数据虽然在线，但发现信息、整理信息、决策辅助仍然靠人。

AI办公的核心变化是：把大模型的理解、生成、推理能力嵌入到日常办公流程中，让软件从“存储和传输信息”变成“理解和加工信息”。

举个例子：

• 传统会议软件只负责把会议录下来，AI会议纪要则能自动生成议程、结论、待办事项。
• 传统知识库需要人手动搜索关键词，AI知识库可以直接用自然语言回答问题，并引用来源。
• 传统文档编辑需要人逐段润色，AI文档能直接根据上下文续写、改写、翻译。

这些能力在2023年之前需要大量NLP工程开发，而现在大模型把理解层和生成层几乎标准化了，所以大厂才有条件在短期内集中上线一批AI办公功能。

1.2 阿里、字节、腾讯各自盯上了哪些场景

虽然三家都有完整的企业办公产品线，但切入侧重点略有不同，这里基于公开功能做简单梳理：

共同点是：都在做“办公入口级AI”，目标是让用户在自己最常打开的办公应用中直接使用AI能力，而不是跳到独立的AI产品里。

1.3 对开发者的启示

大厂做的是通用办公入口，但企业级AI办公需求非常碎片化。每个公司都有自己的合同模板、审批流程、项目文档、历史会议记录，这些数据大厂不会也不可能全部适配。

所以未来的机会点在于：

• 基于大模型API开发企业内部专属的AI办公工具。
• 围绕会议、文档、知识库三个高频场景做垂直产品。
• 在企业私有化部署和数据安全约束下，提供轻量级AI中间件。

这也是本文后面会重点展开的内容。

2. AI办公背后的核心技术栈

从技术上看，一个完整的AI办公应用可以拆成四层：

数据层 -> 模型层 -> Agent/应用层 -> 交互层

下面分别解释每一层。

2.1 大模型调用层

大模型是AI办公的“大脑”。开发者不需要训练模型，而是通过API调用已有的大模型能力。

常见接口能力包括：

• 文本对话（chat/completions）
• 嵌入向量（embeddings）
• 函数调用（function calling/tool use）
• 多模态理解（图片、音频、视频输入）

在办公场景中，文本对话和嵌入向量用得最多。文本对话用于生成会议纪要、润色文档、回答知识库问题；嵌入向量用于知识库的语义检索。

2.2 RAG（检索增强生成）

企业办公场景中，大模型不能直接回答问题，因为它是通用模型，不了解企业内部知识。同时，直接拿企业内部文档做微调也不现实，成本高且更新困难。

RAG是目前最主流的企业知识库方案，流程如下：

1. 把企业文档切片。
2. 将切片内容向量化，存入向量数据库。
3. 用户提问时，先做语义检索，把最相关的切片找出来。
4. 将用户问题 + 检索结果一起发给大模型，生成最终答案。

这样做的核心价值是：

• 不需要训练模型，就能让大模型“知道”企业知识。
• 知识内容可以随时更新，只需要重新向量化即可。
• 可以标注引用来源，增加答案可信度。

2.3 Agent 与函数调用

单纯的问答只是AI办公的第一步。当AI需要主动调用工具、操作数据、完成多步骤任务时，就需要Agent能力。

例如：

• “帮我把上周的会议纪要按照模板整理成周报发送出去。”
• “统计本月所有项目文档中的待办事项，并按截止日期排序。”
• “根据这份合同模板，帮我起草一份新的合作框架。”

这些任务不再是一次性生成，而是需要AI拆解计划、调用工具、循环执行、校验结果。这种能力在大模型中通过函数调用（Function Calling）来实现，或者在更复杂的框架中通过ReAct模式来实现。

2.4 私有化部署与数据安全

企业办公数据非常敏感，很多公司不允许把内部文档直接发送到第三方大模型API。这时候就需要本地模型或私有化网关。

实际项目中通常有几种路线：

• 调用云厂商大模型API，并签署数据安全协议（最简单，适合中小团队）。
• 在私有化环境部署开源大模型，如Qwen系列、DeepSeek等（适合数据敏感企业）。
• 混合架构：敏感数据走本地模型，通用场景走云端API。

这里需要特别提醒：涉及企业数据时，必须先做权限校验、敏感信息脱敏和审计。不要因为AI能力强就忽略数据安全边界。

3. AI办公开发的环境准备

本文后面的代码示例基于Python实现，因为Python在数据处理和AI生态上最方便。如果你所在的团队以Java为主，可以使用Spring AI等框架，但核心思路是一致的。

3.1 开发环境与版本建议

需要注意的是，大模型API的地址、模型名称、密钥这些信息每个服务商都不同，同一个服务商的版本也可能变化。所以代码中我会用环境变量的方式配置，读者按照自己的实际情况填写即可。

3.2 功能设计

我们来实现一个轻量级“AI会议纪要助手”，包含两个核心能力：

1. 根据会议文字稿，自动生成会议纪要和待办事项。
2. 基于内部文档做知识库问答，回答时附带引用来源。

这个项目麻雀虽小，但覆盖了AI办公中最常被提到的两个能力，而且代码可以在本地运行。

4. 实战：从零实现一个AI会议纪要助手

4.1 项目结构

建议创建如下目录结构：

ai-office-assistant/ ├── config.py # 配置 ├── llm_client.py # 大模型调用封装 ├── vector_store.py # 简易向量检索 ├── meeting_notes.py # 会议纪要生成 ├── knowledge_base.py # 知识库问答 ├── main.py # 入口 └── docs/ # 示例知识库文档

4.2 配置管理

在config.py中管理配置，全部通过环境变量读取，避免把密钥写死在代码中。

import os API_KEY = os.getenv("AI_API_KEY", "") API_BASE = os.getenv("AI_API_BASE", "https://api.openai.com/v1") MODEL = os.getenv("AI_MODEL", "gpt-4o-mini") EMBEDDING_MODEL = os.getenv("EMBEDDING_MODEL", "text-embedding-3-small")

如果你的模型服务支持OpenAI兼容格式，可以直接使用。如果不支持，需要根据服务商提供的SDK调整请求部分。

4.3 封装大模型调用

创建一个通用的LLM客户端，包含文本生成和向量嵌入两个方法。

import json import requests class LLMClient: def __init__(self, api_key: str, api_base: str, model: str): self.api_key = api_key self.api_base = api_base self.model = model def chat(self, system_prompt: str, user_prompt: str, temperature: float = 0.3) -> str: url = f"{self.api_base}/chat/completions" headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json", } payload = { "model": self.model, "temperature": temperature, "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt}, ], } response = requests.post(url, headers=headers, json=payload, timeout=60) response.raise_for_status() return response.json()["choices"][0]["message"]["content"]

这里用requests直接调用HTTP接口，是为了避免绑定特定SDK。如果你使用的是某个云厂商的SDK，替换为官方SDK的调用方式即可。

4.4 实现会议纪要生成

在meeting_notes.py中实现核心逻辑。

import json from llm_client import LLMClient def generate_meeting_notes(llm: LLMClient, transcript: str) -> dict: system_prompt = ( "你是一名专业的会议记录助理。请根据用户提供的会议文字稿，" "提取会议关键信息，输出JSON格式结果。" "JSON格式如下：" "{\"summary\": \"会议摘要\", \"decisions\": [\"决策1\"], \"actions\": [{\"task\": \"待办事项\", \"owner\": \"负责人\", \"deadline\": \"截止日期\"}]} " "如果原稿中没有提到负责人或截止日期，请填写\"未提及\"。" "只输出JSON，不要输出多余文字。" ) user_prompt = f"会议文字稿如下：\n{transcript}" raw_output = llm.chat(system_prompt, user_prompt, temperature=0.2) # 避免模型在JSON外添加代码块标记 raw_output = raw_output.strip() if raw_output.startswith("```"): raw_output = raw_output.strip("`") if raw_output.startswith("json"): raw_output = raw_output[4:] raw_output = raw_output.strip() try: data = json.loads(raw_output) except json.JSONDecodeError: # 如果解析失败，退回朴素处理 data = {"error": "模型输出无法解析为JSON", "raw": raw_output} return data

这段代码的关键点：

• 通过system_prompt明确告诉模型输出格式，这是当前大模型应用中最重要的技巧。
• 用temperature=0.2降低随机性，保证结果稳定。
• 做了JSON解析保护，防止模型输出代码块标记导致解析失败。

4.5 实现简易向量存储

生产环境可以使用向量数据库，但为了演示，我们先用Python实现一个基于内存的向量检索。

import math class SimpleVectorStore: def __init__(self): self.chunks = [] self.vectors = [] def add_document(self, chunks: list[str], vectors: list[list[float]]): for chunk, vector in zip(chunks, vectors): self.chunks.append(chunk) self.vectors.append(vector) def cosine_similarity(self, vector_a, vector_b): dot = sum(a * b for a, b in zip(vector_a, vector_b)) norm_a = math.sqrt(sum(a * a for a in vector_a)) norm_b = math.sqrt(sum(b * b for b in vector_b)) if norm_a == 0 or norm_b == 0: return 0.0 return dot / (norm_a * norm_b) def search(self, query_vector, top_k=3): scored = [] for index, vector in enumerate(self.vectors): score = self.cosine_similarity(query_vector, vector) scored.append((score, index)) scored.sort(reverse=True, key=lambda x: x[0]) return [(self.chunks[index], score) for score, index in scored[:top_k]]

4.6 实现知识库问答

在knowledge_base.py中构建RAG流程。

from llm_client import LLMClient from vector_store import SimpleVectorStore def split_text(text: str, chunk_size: int = 200, overlap: int = 50) -> list[str]: """将长文本按固定长度切片，带重叠避免切断语义。""" if len(text) <= chunk_size: return [text] chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) if end >= len(text): break start = end - overlap return chunks def build_knowledge_base(llm: LLMClient, documents: list[str], store: SimpleVectorStore): for doc in documents: chunks = split_text(doc) embeddings = llm.get_embedding(chunks) store.add_document(chunks, embeddings) def ask_knowledge_base(llm: LLMClient, store: SimpleVectorStore, question: str) -> str: query_vector = llm.get_embedding([question])[0] results = store.search(query_vector, top_k=3) context_parts = [] for index, (chunk, score) in enumerate(results): context_parts.append(f"[{index + 1}] {chunk}") system_prompt = ( "你是一名企业内部知识库助手。请根据提供的参考材料回答用户问题。" "要求：如果参考材料中没有相关内容，请明确回答'材料中未找到相关信息'。" "回答结尾请标注引用编号，格式如'（来源：[1]）'。" "不要编造不存在的细节。" ) user_prompt = f"参考材料：\n{'\\n'.join(context_parts)}\n\n用户问题：{question}" return llm.chat(system_prompt, user_prompt, temperature=0.2)

这里需要注意的是，get_embedding方法在之前的LLMClient中没有实现。需要补充如下方法：

def get_embedding(self, texts: list[str]) -> list[list[float]]: url = f"{self.api_base}/embeddings" headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json", } payload = { "model": self.embedding_model, "input": texts, } response = requests.post(url, headers=headers, json=payload, timeout=60) response.raise_for_status() data = response.json() return [item["embedding"] for item in data["data"]]

同时在构造函数中加入embedding_model参数。

4.7 组装主程序

main.py代码如下：

from config import API_KEY, API_BASE, MODEL from llm_client import LLMClient from vector_store import SimpleVectorStore from meeting_notes import generate_meeting_notes from knowledge_base import build_knowledge_base, ask_knowledge_base def main(): llm = LLMClient(api_key=API_KEY, api_base=API_BASE, model=MODEL) # 1. 会议纪要案例 transcript = """ 产品经理张琳：本次会议主要讨论3.0版本发布计划。 技术负责人李强：前端页面已经开发完成，接口联调还需要三天。 测试工程师王芳：测试用例编写了80%，希望周五前开始全量回归测试。 产品经理张琳：那发布窗口定在下周三，大家有风险提前提出来。 技术负责人李强：有一个风险，支付模块的第三方回调还差对方审核。 产品经理张琳：这个我去跟对方商务确认，最晚明天给结论。 """ notes = generate_meeting_notes(llm, transcript) print("会议纪要结果：") print(notes) # 2. 知识库案例 documents = [ "公司内部规定：请假需要提前一天在OA系统提交申请，部门负责人审批。" "连续请假超过三天需要同时抄送HR，并提交工作计划交接说明。", "会议室预订规则：单次预订最长2小时；如需延长，需要重新预订。" "高层会议室优先满足客户接待需求，普通会议建议使用开放讨论区。", ] store = SimpleVectorStore() build_knowledge_base(llm, documents, store) question = "请假流程是什么？" answer = ask_knowledge_base(llm, store, question) print("\n知识库问答结果：") print(answer) if __name__ == "__main__": main()

4.8 运行验证

在终端运行：

export AI_API_KEY="你的密钥" export AI_API_BASE="你的API地址" export AI_MODEL="你的模型名称" python main.py

预期输出分为两部分，第一部分是结构化会议纪要，第二部分是带引用的知识库回答。由于大模型输出具有随机性，即使调低 temperature，不同模型的具体措辞也会不同，这是正常现象。

5. 常见问题与排查思路

实际开发AI办公应用时，大部分问题不在模型能力，而在工程细节。

5.1 会议转写结果乱码或断句错误

这类问题常见于音视频转写环节。解决思路是：

• 优先选用标点恢复能力强的转写服务。
• 在转写前做声道分离和降噪。
• 对Speaker（说话人）进行区分，会议纪要才能标注“谁说了什么”。

5.2 知识库召回不准确

召回准确率直接影响最终回答质量。常见优化方向有：

• 切分策略：从固定长度切分改为按段落/标题切分。
• 混合检索：同时使用关键词检索和向量检索，再做结果融合。
• 重排序：用更精细的rerank模型对召回结果重新打分。

5.3 提示词容易被“套话”

很多人写提示词只写“请总结”，效果不稳定。更好的做法是给出输出结构定义和示例。比如我们上面会议纪要的prompt，明确指定了JSON字段和约束，稳定性就会高很多。

5.4 上下文窗口不够用

办公场景有大量长文本，要注意：

• 会议记录超过模型窗口时，先分段总结，再汇总。
• 知识库问答只带入最相关的切片，不要全文塞入。
• 对话历史需要做滑动窗口截断或摘要压缩。

6. AI办公开发的工程化最佳实践

6.1 数据安全和权限设计

这是AI办公场景中最需要重视的一环。

在企业内部落地时，至少要遵循以下原则：

• 最小权限：用户只能让AI访问自己有权限访问的数据。
• 敏感信息脱敏：手机号、身份证、银行卡等发送给模型前必须先脱敏。
• 审计日志：记录每次AI调用的输入输出，便于追责和复盘。
• 私有化部署：数据不能出域的团队，需要本地部署模型和向量库。

6.2 提示词管理与效果评估

提示词是当前AI应用最重要的“代码”。建议：

• 把提示词独立成文件，不要硬编码在业务逻辑里。
• 使用版本管理，每次修改都记录变更。
• 建立测试集，例如准备20个典型问题，每次修改后都跑一遍回归。

6.3 可观测性与日志

AI应用的输出有不确定性，问题很难复现。因此要记录：

• 完整的用户输入。
• 完整的大模型输出。
• 检索到的文档片段及分数。
• API耗时和token消耗。

这些信息能帮你定位是检索问题、提示词问题还是模型本身的问题。

6.4 成本控制

AI办公应用中，token成本是主要开销。可以这样控制：

• 使用缓存：对相同或相似的请求做结果缓存。
• 压缩上下文：历史消息只保留关键信息，不要无限追加。
• 分级模型：简单任务用小模型，复杂任务用大模型。
• 设置限流：避免用户大量调用造成成本失控。

6.5 异步化处理

办公场景中，会议纪要、文档总结这类任务往往不是用户点一下就能立刻完成的。更合理的方案是采用异步任务：

1. 用户提交任务后立即返回“任务处理中”。
2. 后台通过消息队列异步调用大模型。
3. 任务完成后通过webhook或轮询通知前端。

这样用户体验更好，也能避免HTTP请求超时。

7. 接下来的学习路线

如果你准备深入AI办公方向，建议按以下顺序推进：

1. 先跑通一个最小RAG应用，理解文档切片、向量化、检索、生成的完整链路。
2. 学习提示词工程，重点研究结构化输出、Few-shot、角色设定。
3. 掌握函数调用/Agent模式，让AI能够操作工具、访问数据、主动完成多步任务。
4. 研究多模态能力，把图片、音频、视频纳入办公场景，比如识别截图中的表格、转写会议录音。
5. 了解私有化部署方案，包括开源模型部署、量化、推理加速，这些是企业客户最关心的技术点。

大厂在AI办公上的竞赛，本质上是把大模型能力变成普惠的生产力工具。而对开发者来说，真正的机会不在于复刻一个“通用AI助手”，而在于理解具体业务场景，把AI能力嵌入到真实工作流中，解决那个“只差最后一公里”的问题。

可以先把今天这份演示代码跑起来，再尝试接入你实际使用的会议记录和文档数据。一旦跑通了一个端到端的AI办公流程，后续再扩展Agent、权限、异步任务等能力，会顺利很多。