企业官网建设流程全解析

过去两年，国内几家头部互联网公司在 AI 办公赛道几乎都采用了同样的打法：让多个团队各自立项，做功能重叠的智能助手、知识库产品和内容生成工具，谁能跑出来，资源和流量就给谁。这种“内部赛马”确实帮助公司快速试错，但带来的重复建设也越来越明显。近期行业公开信息里，腾讯、阿里、字节的 AI 办公产品开始出现更明显的收拢迹象，原本分散的助手、文档、会议、知识库能力，正被统一到同一套技术底座上。与其说这是简单的部门合并，不如说是在模型层、数据层、工作流层和权限层做一次统一重构。对开发者和技术决策者来说，与其纠结哪家产品最终胜出，不如先把 AI 办公产品背后的技术链路拆清楚。无论产品怎么合并，底层那套“大模型 + 知识检索 + Agent 工作流 + 权限控制”的骨架不会变。

这篇文章会沿一条主线展开：先解释“赛马”为什么被“合兵”替代，再拆解 AI 办公产品的核心技术件，然后用一个企业会议纪要智能体作为案例，从需求、代码、参数、权限和排错五个角度完整过一遍。目标不是预测哪家产品能赢，而是让你能在自己的企业或项目里，快速复现一套可落地的 AI 办公能力。

1. 为什么大厂 AI 办公产品从“赛马”转向“合兵”

1.1 内部赛马的初衷与代价

内部赛马是一种典型的组织激励方式。多个团队面向同一个用户场景做产品，管理层不提前判定谁对谁错，让市场、数据和用户反馈来筛选方案。在 AI 办公产品刚兴起时，这种方式的价值很明显：大模型能做什么、不能做什么，大家都还在试探，多几个团队并行试错，可以更快找到 PMF。

但赛马的代价在办公场景里被放大了。办公产品天然涉及多人协作、组织架构、企业数据权限和流程审批。多个团队如果各自做一套文档助手、会议助手、知识库问答，就会出现几个典型问题：

• 模型接入重复建设。每个团队都要接大模型 API，都要处理限流、鉴权、计费和模型版本升级。
• 数据资产无法共享。用户在企业 IM 里沉淀的对话、会议纪要、文档和知识库散落多处，每一个智能助手只能看到自己那一小块数据。
• 权限体系不一致。A 团队的智能助手允许员工读取部门文档，B 团队的助手却没有接入同样的身份系统，数据越权风险很高。
• 用户入口碎片化。员工办公要记住多个机器人入口，违背了“用一个统一助手处理工作”的直觉。

这些成本在赛马初期可以忍受，因为产品还没跑起来。但当每个团队都开始进入规模化推广阶段，底层不统一的代价就会超过试错收益。

1.2 模型能力趋同后，产品整合才有更大杠杆

大模型 API 的能力正在快速趋同。各家厂商的基础模型在通用对话、文本摘要、代码生成等任务上的差距越来越小，真正决定办公产品体验的，已经不再是“谁的模型更聪明”，而是：

• 谁的企业知识库覆盖更全、更新更快；
• 谁的工作流引擎能稳定串联审批、提醒、日程和文档；
• 谁的权限系统能和真实组织架构无缝对齐；
• 谁能把 Agent 的一次任务调用成本控制在合理范围。

这时候把多个产品合到同一套底座上，杠杆效应非常明显。模型网关统一后，产品可以按任务自动路由到不同模型，高精度摘要走大参数模型，简单分类走小参数模型，成本得到控制。知识库统一后，会议纪要、项目文档、客户资料可以互相引用，智能体回答问题的质量才有保障。权限统一后，所有入口共享同一套身份系统，风险面大幅缩小。

所以“合兵”本质上是把一个赛马阶段的创新放大器，转成统一底座上的能力放大器。

1.3 “合兵”不是结束，而是技术底座的统一

对一线开发者来说，最值得关心的不是组织架构怎么调整，而是未来 AI 办公产品的开发方式会发生什么变化。过去是“每个产品各自接模型、各自造轮子”，未来更像是“平台提供一套 AI 能力底座，业务方在上面做场景化配置”。

这种变化会体现在几个层面：

对开发者来说，这是一次开发范式迁移：过去要自己从头实现“用户输入 -> 模型生成”的串行链路，未来会更像“注册一个技能、配置一段 Prompt、挂一个数据源、发布到统一入口”。但这不代表不需要掌握底层技术，恰恰相反，只有理解 RAG、Agent、工作流和权限控制，才能在平台抽象之上做好场景化调优。

2. AI 办公产品不是“一个聊天机器人”，而是一套技术组合

2.1 四个核心组件：大模型、知识库、Agent 和工作流

很多人第一次接触 AI 办公产品时，会把它理解成一个聊天机器人。用户输入问题，机器人返回答案，仅此而已。真实的企业办公场景要复杂得多。

一条典型的“帮我整理今天上午的项目会纪要，并把待办同步给相关同事”需求，至少要经过四个技术组件：

• 大模型：负责理解自然语言、生成摘要、抽取待办和风险。
• 知识库：存储历史会议、项目文档、团队规范，让模型在生成前能检索到相关事实。
• Agent：把“整理纪要、提取待办、同步同事”拆解成多个步骤，并决定调用哪些工具。
• 工作流：承载固定的业务规则，例如纪要必须经过 Leader 审批、待办必须同步到项目管理工具。

这四个组件不是互相替代的关系。大模型负责“理解和生成”，知识库负责“补充事实”，Agent 负责“规划与执行”，工作流负责“约束和兜底”。没有知识库，模型容易胡编；没有 Agent，多步骤任务无法自动完成；没有工作流，结果无法和真实业务系统对接。

2.2 一次典型的 AI 办公请求链路

一次标准请求通常可以拆成下面几步：

1. 用户输入自然语言请求。
2. 统一入口完成身份认证和数据权限校验。
3. Agent 识别意图并拆解子任务。
4. 对需要外部信息的子任务，从知识库或业务系统检索上下文。
5. 将用户输入、检索结果、系统提示词组合成完整上下文。
6. 调用大模型生成结果。
7. 对模型输出做格式校验和业务校验。
8. 把结果写回文档、IM 或项目管理系统。

用伪代码表示就是：

def handle_meeting_request(user_input, user_context): check_permission(user_context) plan = agent.plan(user_input) context = retrieve_context(plan) prompt = build_prompt(user_input, context, plan) raw_output = llm.chat(prompt) validated = validate_output(raw_output) write_back(validated) return validated

这里每一步都有独立的工程问题。权限校验如果放在模型调用之前，可以提前拦截越权请求，避免把敏感数据送进模型。检索上下文如果做得好，模型生成质量会明显提升。输出校验如果不做，模型返回的 JSON 字段缺失会在下游业务系统里造成连锁故障。

2.3 为什么 Agent 会成为办公产品标配

办公场景和日常聊天最大的区别是任务往往有明确目标、依赖外部工具、需要多步骤执行。过去这些任务靠人工完成：整理纪要、发通知、查客户资料、填审批单。现在 Agent 可以把“感知 -> 规划 -> 行动 -> 反馈”的闭环自动化。

一个会议助手的典型 Agent 规划大致是这样：

• 任务 1：把会议语音转写文本压缩成 500 字纪要；
• 任务 2：从纪要中提取决策项；
• 任务 3：从决策项中识别待办，标注负责人和截止时间；
• 任务 4：通过待办接口创建任务；
• 任务 5：把纪要链接发送到会议群。

每一步可以单独调模型，也可以调工具接口。Agent 的价值不是一次性生成一段长文本，而是把一个模糊指令拆成一系列可验证、可追踪、可修复的子任务。这点在办公产品里尤其重要，因为做错一个环节，负责人会收到错误信息，直接影响协作效率。

2.4 关键技术术语速查

在开始写代码前，先把后面会用到的几个概念对齐。

理解这些术语后，再看大厂的 AI 办公产品，会发现它们都是在同一套概念上做的产品化封装。区别只在于各自的数据规模、业务场景和生态开放程度不同。

3. 实战：从零搭一个企业会议纪要智能体

3.1 先拆需求，不要急着调接口

无论用什么模型，第一步都是把需求拆清楚。这里以一个会议纪要智能体为例，输入是一段会议转写文本，输出是一份结构化纪要。

业务需求可以拆成这几条：

• 输入：会议转写文本，可能是 5000 字，也可能更长；
• 输出：会议摘要、决策项、待办事项、风险问题；
• 约束：输出必须是稳定 JSON，待办项里要包含负责人和截止时间；
• 扩展：后续能查询历史会议、能把待办同步到项目管理工具。

对应的技术拆解是：

初学者最容易犯的错，是一上来就写模型调用代码，忽略输出结构和校验逻辑。结果模型返回一段格式漂移的文本，下游没法用。

3.2 环境准备与依赖选择

示例使用 Python 3.10 及以上版本。安装依赖时，建议先建一个虚拟环境，避免污染系统 Python。

python3 -m venv .venv source .venv/bin/activate pip install openai pydantic python-dotenv chromadb

依赖包的用途如下：

• openai：兼容 OpenAI 协议的大模型客户端 SDK。国内多家大模型服务商都提供兼容接口，实际使用时以你选择的供应商文档为准。
• pydantic：定义输入输出结构，做数据校验。
• python-dotenv：从.env文件读取 API Key，避免把密钥写进代码。
• chromadb：本地向量数据库，用于把历史会议文本转成可检索的向量。

如果你的技术栈是 Java，可以考虑 Spring AI。它提供了ChatClient抽象，底层屏蔽了不同大模型 API 的差异。下面示例基于 Python，因为更通用，也更容易展示数据校验逻辑。

3.3 先定义数据结构

大模型返回的是文本，但在办公系统里，更好的做法是让模型返回结构化 JSON，再用 Pydantic 校验。先定义一个会议纪要的数据模型：

from pydantic import BaseModel, Field from typing import List class ActionItem(BaseModel): task: str = Field(description="需要跟进的具体任务") owner: str = Field(description="负责人") due_date: str = Field(description="截止日期，格式 YYYY-MM-DD") class RiskItem(BaseModel): risk: str = Field(description="风险描述") level: str = Field(description="风险等级，low/medium/high") class MeetingSummary(BaseModel): summary: str = Field(description="会议摘要，控制在 300 字以内") decisions: List[str] = Field(description="本次会议达成的决策") actions: List[ActionItem] = Field(description="待办事项") risks: List[RiskItem] = Field(description="风险问题")

这段代码有两个作用。第一，它告诉读者最终要什么结构；第二，它会被用来做模型输出校验。真实项目里，字段名要和业务团队提前对齐，避免下游系统解析不一致。

3.4 最小模型调用代码

下面写一个可运行的大模型调用函数。这里用到的是 OpenAI SDK 兼容接口，实际base_url和api_key需要替换为你所使用的大模型服务商提供的信息。

import os import json from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL"), # 替换为合规的大模型服务地址 ) SYSTEM_PROMPT = """ 你是一个企业会议纪要助手。你会收到一段会议转写文本，请生成结构化 JSON。 JSON 字段必须严格遵循以下结构： { "summary": "会议摘要", "decisions": ["决策1", "决策2"], "actions": [ {"task": "任务描述", "owner": "负责人", "due_date": "YYYY-MM-DD"} ], "risks": [ {"risk": "风险描述", "level": "low/medium/high"} ] } 不要输出 JSON 以外的任何解释文字。 """ def build_meeting_summary(transcript: str) -> dict: response = client.chat.completions.create( model="your-model-name", response_format={"type": "json_object"}, messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"会议转写文本：\n{transcript}"}, ], temperature=0.2, max_tokens=2000, ) content = response.choices[0].message.content return json.loads(content)

这段代码的关键点有三个：

• response_format={"type": "json_object"}：要求模型输出 JSON，但不是模型一定不会出错，仍然需要 try/except。
• temperature=0.2：办公场景里对输出稳定性要求高，不要开太高。摘要和抽取任务建议 0 到 0.3。
• max_tokens=2000：限制输出长度，防止模型在长文本上失控。

调用后，用 Pydantic 校验：

def parse_meeting_summary(raw: dict) -> MeetingSummary: return MeetingSummary.model_validate(raw)

如果字段缺失或类型不对，Pydantic 会抛出明确异常。不要直接把json.loads的结果拿给业务系统用。

3.5 接入 RAG：让纪要能引用历史知识

只有会议转写文本时，模型只能做“总结”，不能回答“我们这个月和上个月的排期有什么冲突”。为了让智能体有记忆力，可以把历史会议记录写入向量数据库。

先建一个集合，并插入历史会议文本：

import chromadb client_db = chromadb.PersistentClient(path="./meeting_db") collection = client_db.get_or_create_collection("meetings") def index_meeting(meeting_id: str, transcript: str): # 简单按段落切分，正式项目可以用更细致的分块策略 chunks = [transcript[i:i + 1000] for i in range(0, len(transcript), 1000)] collection.add( ids=[f"{meeting_id}-{i}" for i in range(len(chunks))], documents=chunks, metadatas=[{"meeting_id": meeting_id} for _ in range(len(chunks))] )

在用户提问时，先从向量库中检索相关片段：

def retrieve_context(query: str, top_k: int = 3) -> str: results = collection.query(query_texts=[query], n_results=top_k) docs = results["documents"][0] return "\n---\n".join(docs)

检索到的上下文会拼接进用户消息，让模型基于事实回答。这里要注意：小项目可以直接把检索结果放进 Prompt，生产环境则要加入权限过滤，确保用户只能检索到有权访问的会议。

3.6 参数调优：先理解再调参

大模型接口参数表如下：

实际项目里不要先调参，要先观察输出。如果摘要内容精准但偶尔格式错误，优先用response_format和输出校验。如果模型回答死板，再考虑提高temperature。调参要一次只改一个变量，不然没法定位问题。

4. 办公场景里的工程细节：权限、数据安全与结果校验

4.1 模型接入方式选择：不是只有公网 API 一种答案

学习环境下，可以直接调用大模型服务的在线 API。生产环境则要考虑数据合规和链路稳定性。企业通常有三种接入方式：

• 使用云厂商提供的公网 API，数据会经过服务商，适合非敏感、已脱敏的办公文本。
• 通过专线或内网网关访问私有化部署的大模型，适合涉密数据。
• 在本地 GPU 环境部署开源模型，适合对延迟和可控性要求极高的场景。

选择时不能只看模型效果，要评估数据出域合规、成本、并发和运维复杂度。如果你的会议纪要里包含客户手机号、合同金额，建议至少先做脱敏，再调用外部 API。

4.2 数据脱敏：模型不需要知道所有原始信息

办公文本里最常见的敏感信息是手机号、邮箱、身份证号、项目代号和客户名。可以在进入模型前做规则脱敏：

import re def desensitize(text: str) -> str: text = re.sub(r"1[3-9]\d{9}", "[手机号]", text) text = re.sub(r"\b\d{6}\b", "[数字编号]", text) return text

脱敏后的文本仍然保留了语义上下文，但敏感字段不会进入模型。生成结果之后，再根据业务需要决定是否还原。如果业务系统必须要原始信息，那就要考虑私有化部署，而不是把原始数据送出去。

4.3 权限隔离：要在模型调用之前做

很多 AI 办公产品的安全事故，不是模型“越权”，而是应用层根本没做权限隔离。用户 A 搜索“项目报价”，向量数据库把用户 B 才能看到的会议片段也检索了出来，模型基于这些内容生成答案，数据就泄露了。

权限隔离有三个层次：

• 身份认证：确认“当前用户是谁”。
• 数据授权：确认“该用户能访问哪些会议、文档、群组”。
• 检索过滤：在向量检索时把文档元数据和用户权限做交集。

简单实现可以在向量库的 metadata 中加入allowed_users或allowed_dept：

collection.add( ids=["meeting-001"], documents=["会议内容..."], metadatas=[{ "allowed_users": ["zhangsan", "lisi"], "allowed_dept": "product" }] )

查询时根据当前用户上下文过滤候选文档。不要只靠 Prompt 对模型说“你只能访问有权限的内容”，模型没有真正的数据访问控制能力，权限必须在应用层执行。

4.4 结果校验与日志：模型输出不能直接入库

模型输出进入业务系统前必须完成三道校验：

1. 格式校验：能用MeetingSummary.model_validate()验证字段；
2. 业务校验：负责人是否存在于通讯录，截止日期是否合法；
3. 逻辑校验：待办是否从会议讨论中产生，有没有凭空编造。

建议每次调用都记录结构化日志：

{ "event": "meeting_summary_generate", "request_id": "8f2a...", "model": "your-model-name", "prompt_tokens": 3200, "completion_tokens": 420, "latency_ms": 1800, "temperature": 0.2, "result_status": "success" }

这组日志在排查问题时非常关键。出现用户投诉“智能体乱回答”，如果没有请求日志，就只能靠猜。日志至少要保留 prompt 摘要、token 用量、耗时和错误码，但不要记录完整敏感正文。

5. 常见问题排查：从现象倒推根因

5.1 统一排查顺序

AI 办公应用报错，不要上来就怀疑模型。按下面顺序排查：

1. 输入是否正确：用户请求是否被正确解析，有没有截断。
2. 权限是否通过：用户身份和数据权限是否在模型调用前完成校验。
3. 检索结果是否相关：向量库返回的片段是否和问题有关。
4. Prompt 是否正确：系统提示词有没有被用户输入覆盖，格式约束是否写清楚。
5. 模型输出是否稳定：多次调用结果是否一致，是否出现 JSON 解析失败。
6. 下游写回是否成功：待办是否真的创建成功，还是接口报错。
7. 依赖版本是否匹配：SDK、模型服务接口、向量库版本是否一致。

5.2 快速定位问题表

5.3 一个典型排错过程：模型一直输出 JSON 之外的说明文字

现象是调用接口后，json.loads(content)抛出异常，错误信息是模型在 JSON 前后加了“好的，这是整理后的纪要：”之类的话。

根因不是模型“笨”，而是没有充分约束输出。response_format能提高 JSON 输出概率，但如果你在前一次调用里没有使用，或者系统 Prompt 里没有给示例，模型仍然会回归到习惯性回复。

解决分两步。

第一步，在messages里补一条 system 消息：

SYSTEM_PROMPT = """ 只输出 JSON，不要输出任何解释、前缀或后缀。 JSON 结构如下：... """

第二步，启用response_format，并加一层兜底解析：

def parse_model_output(content: str): # 尝试直接解析 try: return json.loads(content) except json.JSONDecodeError: # 去掉可能的代码块标记 cleaned = content.replace("```json", "").replace("```", "").strip() start = cleaned.find("{") end = cleaned.rfind("}") return json.loads(cleaned[start:end+1])

兜底解析只适合做临时修复，生产环境应该依赖格式校验和失败重试，而不是花大量代码去“修复”模型的输出格式。

6. 在“合兵”趋势下怎么做技术选型和学习规划

6.1 三条技术路线：买成品、用平台 API、自己搭建

不同团队的资源条件差异很大，选择路线不能只看技术趋势，还要看人员、数据和场景复杂度。

实际项目里，三条路线不一定互斥。很多企业会用成品工具做员工个人效率提升，同时用平台 API 搭建核心业务系统里的智能助手，再把涉密数据分析放在私有化环境。

6.2 平台化选型时关注什么

当大厂把 AI 办公产品合兵之后，平台 API 会越来越标准化。选型时建议关注五个方面：

• 模型网关是否透明：能否自主配置不同模型，而不是被绑死在一个模型上。
• 知识库是否开放：能否把自己的文档、数据库和 API 接入，而不是只能用平台内置数据。
• Agent 能力是否可编程：支持 Function Call、支持自定义工具，还是只能配置固定流程。
• 权限模型是否完整：用户、角色、数据范围、审计日志是否齐全。
• 私有化/混合部署是否可行：如果是金融、政务或企业敏感场景，这一点直接决定能否采用。

列成检查清单就是：

[ ] 是否支持通过 API 调用对话、摘要、抽取能力 [ ] 是否支持自定义 Prompt 和输出 JSON Schema [ ] 是否支持接入自有知识库，是否有数据权限过滤 [ ] Agent 能否调用内部系统 API [ ] 是否提供请求日志、模型版本、token 用量和审计能力 [ ] 是否支持私有化部署或混合部署 [ ] 是否有明确的限流、误用和失败降级方案 [ ] 是否提供评测工具，能对比不同模型在同一业务上的效果

这份清单可以作为项目立项时的评审条目，也可以在采购产品前发给厂商确认。

6.3 技术学习路径，不要只学 Prompt

面对 AI 办公产品“合兵”，新手容易产生两种极端心态：一种是觉得工具会取代开发者；另一种是觉得大厂会做完所有事，自己没必要学底层。实际上，未来需求量最大的岗位，是那些“能理解业务、能设计 RAG、能写 Agent 工作流、能处理权限与安全问题”的人。

一条比较实际的学习路径：

1. 完成一个最小闭环：调用大模型 API，对一段会议文本生成结构化 JSON。
2. 加入向量检索：把会议记录索引到向量库，实现“基于历史会议提问”。
3. 加入权限控制：让不同用户只能检索各自权限范围内的文档。
4. 加入工具调用：通过 Function Call 把待办写入任务系统。
5. 加入评测：准备 30 条测试样本，对比不同 Prompt 和模型的效果。
6. 加入可观测性：输出结构化日志，建立失败率、延迟和成本指标。

每一步都是可独立交付的小功能。全部完成后，你就有了一套接近真实生产环境的 AI 办公助手。

7. 收尾：抓住不变的技术骨架

7.1 核心判断

腾讯、阿里、字节的 AI 办公产品从“赛马”走向“合兵”，是行业从模型探索期进入产品成熟期的信号。对开发者来说，最重要的判断是：AI 办公产品的护城河不在模型本身，而在数据、工作流、权限和场景化体验。无论产品组织怎么调整，底层需要解决的问题始终是“如何让模型在正确的数据范围内、遵循正确的业务流程、生成可校验的结构化结果”。

这也解释了为什么单纯的“套壳”应用很难长久。没有知识库，模型只能泛泛而谈；没有权限体系，产品不敢在企业里推广；没有工作流引擎，AI 结果无法真正驱动业务。真正有价值的，是把 AI 能力嵌入具体工作链路的能力。

7.2 下一步可以做的练习

如果你想把这篇文章里的内容转化成自己的技能，建议从一个小项目开始：把你所在团队的周报、会议纪要或项目文档收集起来，写一个智能助手，先让用户提问、摘要、提取待办，再加权限过滤和知识库检索。

做完这个项目后，你会更深刻地理解三件事：

• 模型输出不稳定，所以需要结构化约束和校验；
• 数据不统一，所以需要 RAG 和知识库建设；
• 用户不信任黑盒，所以需要日志、解释来源和人工确认机制。

这三件事，正是大厂 AI 办公产品“合兵”后真正想解决的问题。抓住它们，无论产品名字怎么换、底座怎么迁移，你的技术积累都不会过时。