企业官网建设流程全解析

办公 Agent 的爆火，把模型竞争从“谁的参数更多、谁的榜单分数更高”拉回到了“谁能真正替用户把活干完”。在办公场景里，写周报、整理会议纪要、分析销售数据、起草邮件这些任务，过去需要人手动在多个系统之间切换，现在由一个 Agent 串联模型、工具和记忆就能完成。所谓办公 Agent，不是简单的聊天机器人，而是一套能够感知任务、拆解步骤、调用工具、观察结果并继续执行的系统。模型大战进入下一阶段后，比拼的不再只是模型本身，而是模型与工具链、框架、部署、安全和排障能力的综合工程水平。

这篇文章不写概念空谈，直接从工程视角拆解办公 Agent 为什么火、底层模型如何选、服务如何部署、报错怎么排，最后附上一份可以带走的生产落地检查清单。无论你是准备在团队里引入 Agent，还是正在从零搭建自己的办公自动化项目，都可以按这条链路走一遍。

1. 办公 Agent 为什么突然爆发，核心驱动力是什么

1.1 从对话助手到任务执行者的转变

过去两年里，大多数人接触到的“AI 助手”其实是对话机器人：用户提问，模型生成一段回答。用户拿到回答之后，仍然需要自己去 Excel 里拉数据、去飞书或钉钉里翻文档、去邮件系统里粘贴内容。任务没有闭环，价值自然有限。

办公 Agent 的本质变化是角色从“建议者”变成“执行者”。当用户说“帮我提取今天的销售明细，按区域汇总后生成一份周报草稿”，Agent 会做这样几件事：

• 解析意图，判断需要访问数据源；
• 调用销售系统或数据库查询接口，拉取数据；
• 调用分析工具或代码解释器，完成汇总计算；
• 调用文档生成接口，把结果写入周报模板；
• 最后把草稿返回给用户确认。

整个过程中，模型负责决策，工具负责执行，记忆负责保存中间状态。用户不再需要把模型生成的内容复制到另一个系统里，而是直接拿到一个可用的结果。这个转变是办公 Agent 爆火的最直接原因。

1.2 模型能力增强带来的连锁反应

模型能力是办公 Agent 能否规模落地的前提。早期的语言模型生成能力弱、上下文长度短，让它按照 JSON 格式输出工具参数都很容易出错。现在的模型在几个关键能力上都有了明显提升：

• 长上下文：可以一次性容纳多份文档、多轮工具调用结果；
• 指令遵循：能严格按照系统提示词完成工具参数格式化；
• 函数调用：原生支持 function calling，模型可以直接输出“调用哪个工具、传什么参数”；
• 复杂推理：面对多步骤任务时，能拆解出可执行的子任务。

这些能力叠加之后，Agent 的编排层就不再需要写死每一个分支，而是让模型在每一步决定下一步做什么。于是 Agent 框架、工具生态、模型服务化平台开始爆发，办公场景成为最快见效的落地领域。

1.3 办公 Agent 适合哪些业务场景

并不是所有办公场景都适合立刻上 Agent。判断标准很简单：任务是否重复、工具是否可调用、结果是否可以自动校验。下面这些场景在常见办公项目中优先级较高：

这里要注意一个常见误解：不是“用了 Agent 就一定比人快”。如果业务系统本身没有开放接口，数据只能靠人工复制粘贴，Agent 的价值就会大打折扣。办公 Agent 的落地优先级，应该先选“工具链完整、流程清晰、人工重复劳动多”的场景。

2. 办公 Agent 的技术链路，先看完整架构再动手

2.1 一个典型办公 Agent 的模块拆分

一个能在生产环境运行的办公 Agent，通常不只是一个 Python 脚本，而是由多个职责明确的模块组成。我习惯把架构拆成六层：

分层的核心原因是可维护性。如果所有逻辑都写在一个 Agent 类里，初期跑通很快，一旦工具增加到几十个，模型升级、权限调整、异常排查都会变得非常痛苦。实际项目中，我建议先按“编排层、工具层、记忆层”三条线切分，再逐步补充权限和审计。

2.2 计划、工具调用和记忆机制

办公 Agent 的编排层最常用的模式是 ReAct：Reasoning 和 Acting 交替进行。模型每一次输出可以有两种选择，要么给出最终答案，要么输出一个工具调用请求。系统执行工具后，把结果拼回上下文，让模型继续推理，直到任务完成。

一个最简循环可以这样理解：

用户输入 -> Agent 拆解任务 -> 模型决定调用哪个工具，输出结构化参数 -> 执行工具，返回结果 -> 模型结合结果继续推理 -> 重复，直到模型输出最终答案

这个循环中最容易被忽略的是记忆。办公任务通常不是一轮对话就结束，比如“先查上周数据，再对比本月数据，最后生成报告”，每一步都需要引用前面的结果。短期记忆可以直接放在上下文里，但长期记忆必须外置到向量数据库或结构化存储中。

工具调用在现代模型中通常通过 function calling 完成。模型看到工具描述后，输出类似下面的 JSON：

{ "name": "query_sales_data", "arguments": "{\"start_date\": \"2025-05-01\", \"end_date\": \"2025-05-07\", \"region\": \"华东\"}" }

实际项目中，工具描述写得越清楚，模型选择正确工具的概率越高。工具名要语义明确，参数说明要给出取值范围和示例，避免让模型“猜”。

2.3 Agent 框架选型对比

目前办公 Agent 的框架选择非常多，常见的有 LangChain、LlamaIndex、AutoGen、Dify、Coze，也有团队自己实现精简循环。它们之间的差异不在“能不能做 Agent”，而在“多快能上手、多方便扩展、多容易维护”。

如果是刚开始学习，不建议一上来就引入重型框架。可以先自己写一个 50 行左右的 function calling 循环，理解清楚模型输出、工具执行、结果回填这三个环节，再决定要不要用框架。这样即使以后切换到 LangChain 或 Dify，也不会被框架的黑盒逻辑困住。

3. 模型能力是底座，从 Transformer 到模型融合与蒸馏

3.1 Transformer 仍然决定 Agent 的上下文理解上限

办公 Agent 的所有能力，最终都建立在语言模型对上下文的理解之上。现在的生成式模型几乎都是 Transformer 架构，核心机制是自注意力（Self-Attention）。自注意力让模型在处理一个词的时候，能够同时关注句子中所有其他词，从而理解长距离依赖关系。

放到办公 Agent 场景里，这个机制决定了三件事：

• Agent 能否读懂一段 5000 字的会议记录，并定位到“待办事项”；
• Agent 能否在多次工具调用后，还记得最开始用户的需求；
• Agent 能否把工具返回的表格数据和用户的提问关联起来。

这也是为什么模型“上下文长度”会成为 Agent 选型的重要指标。上下文越长，Agent 能在一次任务里携带的材料越多，但代价是推理延迟和显存占用上升。实际项目中，不要只看模型宣传的最大上下文长度，还要看“有效上下文”。当上下文塞满无关日志时，模型的真实理解能力会明显下降。

3.2 模型融合与模型蒸馏在什么场景下使用

模型融合和模型蒸馏，是办公 Agent 成本优化中经常出现的两个概念，但两者解决的问题完全不同。

模型融合的核心是“让多个模型协同”。实践中常见的做法有两种：一种是把同一个问题同时发给多个模型，通过投票或评分选最优结果；另一种是“按任务路由”，比如意图识别用小型模型，生成报告用大型模型，动作决定用专有模型。后者在办公 Agent 中更实用，因为不是每一步都需要最强的模型。

模型蒸馏的核心是“用大模型教小模型”。团队可以在私有数据上，让大模型生成一批高质量的用户意图分类、工具选择、摘要结果作为训练数据，再微调一个小模型。小模型部署成本低、推理快，适合放在流量高的前置环节。

实际工程中，办公 Agent 通常先使用单一大模型跑通流程，再根据监控数据决定哪些环节可以用小模型替换。过早优化模型成本，往往会拖慢功能迭代。

3.3 向量模型和 reranker 模型在办公 Agent 里的分工

办公 Agent 要读取企业文档、邮件、合同，不可能把全部内容塞进 prompt。常见做法是先通过检索找出最相关的片段，再把片段拼进上下文。这个过程中有两个模型各司其职：

• 向量模型（Embedding Model）：把文本转换成向量，用于在海量文档中做相似度召回；
• 重排模型（Reranker）：对召回结果做精细化排序，把真正相关的文档排在前面。

这里有一个很容易踩的坑：很多团队只用了 embedding 模型做检索，没有 reranker。embedding 模型在高维向量空间里计算“语义相似度”，但对于“用户问的是 A 品牌的退换货政策，文档里同样出现 B 品牌和退换货”这种细粒度问题，向量召回的结果未必准确。reranker 模型直接计算“问题-文档片段”的匹配程度，虽然速度慢一些，但排序质量明显更好。

生产环境里，推荐“向量召回 + reranker 精排”组合。先通过 embedding 从几十万份文档中召回前 20 个候选，再用 reranker 精排取前 3 个拼接进上下文。这样可以兼顾召回速度和精度。

4. 部署办公 Agent 时的模型服务化，以 vLLM 为例

4.1 为什么办公 Agent 需要独立部署 embedding 和 reranker

办公 Agent 在做 RAG 检索时，embedding 和 reranker 的请求模式与生成式大模型完全不同。生成模型处理的是“用户问题 + 上下文片段”的生成任务，单次请求耗时可能几秒到几十秒；embedding 模型则需要在文档导入时批量把文本转成向量，请求量大、单次耗时短；reranker 模型介于两者之间，需要在每次问答时对候选片段打分。

如果三个功能共用同一个服务，会出现明显问题：批量向量化任务占满 GPU 显存时，问答请求被阻塞；生成模型的长请求排队时，reranker 的短请求迟迟得不到响应。更合理的做法是拆分部署：

• 大模型服务：负责生成和决策，使用 GPU 推理框架启动；
• 向量模型服务：负责文本向量化，可以部署在 CPU 或低配 GPU 上；
• reranker 服务：负责候选精排，通常也单独部署。

这样每个服务可以独立扩缩容。文档入库时大量跑 batch 任务，只扩容向量服务；白天高并发问答时，重点保障大模型和 reranker 服务。

4.2 vLLM 启动大模型和 embedding/reranker 的配置差异

vLLM 是目前最常用的高吞吐推理框架，主要针对自回归生成模型做了 PagedAttention 等优化。启动一个大语言模型非常直接：

vllm serve Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192

启动成功后，客户端可以通过 OpenAI 兼容接口调用：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [ {"role": "user", "content": "请把这句话改写成周报格式"} ] }'

但这里要特别提醒：vLLM 的算子优化和功能支持范围主要面向生成式模型。对于 embedding 模型和 reranker 模型这类基于双向编码器或跨编码器的模型，vLLM 的支持情况并不像大模型那么稳定。很多项目里，embedding 和 reranker 会单独使用其他推理服务启动，例如：

# 使用 text-embeddings-inference 启动 embedding 模型 text-embeddings-router \ --model-id BAAI/bge-m3 \ --port 8001

# 使用 cross-encoder 服务启动 reranker 模型 python -m reranker_server \ --model BAAI/bge-reranker-v2 \ --port 8002

这里代码只是示例，真实环境要结合自己的模型管理平台调整。如果你确实想用 vLLM 统一启动，一定要先确认 vLLM 版本和硬件驱动是否支持对应模型架构，不要默认“所有模型都能用 vLLM 跑起来”。

4.3 昇腾 910b-a2 等国产卡环境下的常见问题

不少团队在办公 Agent 落地时会遇到国产加速卡部署问题，比如热搜里出现的“昇腾 910b-a2 服务器上不能通过 vLLM 启动 embedding 向量和 reranker 模型”。这不是配置写错这么简单，而是涉及硬件、算子、框架三层匹配。

排查这类问题，我建议按“模型先本机跑通 -> 再单卡跑通 -> 再上推理框架 -> 再对接 Agent”的顺序推进。不要在 Agent 整个链路都连好的情况下再回头排查模型部署问题，那样很难定位是哪一层出了问题。

5. 从零搭建一个最小办公 Agent 示例

5.1 项目结构和依赖

为了把前面讲的架构落到代码里，这里给出一个不依赖重型框架的最小办公 Agent。它只做三件事：根据用户指令查询销售数据、计算汇总、生成回应。

项目结构如下：

office_agent/ ├── main.py # 入口，启动交互循环 ├── agent.py # Agent 编排，调用模型和工具 ├── tools.py # 工具实现，如销售数据查询 ├── memory.py # 简单的短期记忆存储 ├── config.yaml # 模型服务地址、参数配置 └── requirements.txt

requirements.txt：

openai>=1.0.0 pyyaml>=6.0 requests>=2.28.0

这里使用 OpenAI 兼容接口，方便对接 vLLM 或云端模型服务。

5.2 Agent 核心代码：规划、工具调用、记忆

先看 tools.py，实现一个模拟的销售数据查询工具：

# tools.py import json from datetime import datetime def query_sales_data(start_date: str, end_date: str, region: str = None): """模拟查询销售数据。生产环境这里应改成真实的数据库或 API 调用。""" # 硬编码数据仅用于演示，真实项目不要这样写 data = [ {"date": "2025-05-01", "region": "华东", "amount": 12800}, {"date": "2025-05-02", "region": "华东", "amount": 14300}, {"date": "2025-05-01", "region": "华南", "amount": 9200}, ] result = [] for row in data: if start_date <= row["date"] <= end_date: if region and row["region"] != region: continue result.append(row) return json.dumps(result, ensure_ascii=False) TOOLS = { "query_sales_data": { "description": "查询销售数据。可以按日期范围和区域过滤。", "parameters": { "type": "object", "properties": { "start_date": {"type": "string", "description": "开始日期，格式 YYYY-MM-DD"}, "end_date": {"type": "string", "description": "结束日期，格式 YYYY-MM-DD"}, "region": {"type": "string", "description": "区域，可选：华东、华南、华北"} }, "required": ["start_date", "end_date"] }, "function": query_sales_data } }

再来看 agent.py，实现核心循环：

# agent.py import json from openai import OpenAI class OfficeAgent: def __init__(self, api_base, api_key, model): self.client = OpenAI(base_url=api_base, api_key=api_key) self.model = model self.messages = [] def run(self, user_input: str) -> str: self.messages.append({"role": "user", "content": user_input}) max_steps = 5 for _ in range(max_steps): response = self.client.chat.completions.create( model=self.model, messages=self.messages, tools=[{ "type": "function", "function": { "name": "query_sales_data", "description": "查询销售数据", "parameters": { "type": "object", "properties": { "start_date": {"type": "string"}, "end_date": {"type": "string"}, "region": {"type": "string"} } } } }], tool_choice="auto" ) message = response.choices[0].message tool_calls = message.tool_calls if not tool_calls: self.messages.append({"role": "assistant", "content": message.content}) return message.content # 执行工具调用 self.messages.append(message) for tool_call in tool_calls: func_name = tool_call.function.name args = json.loads(tool_call.function.arguments) if func_name == "query_sales_data": result = TOOLS[func_name]["function"](**args) else: result = json.dumps({"error": "unknown tool"}) self.messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result }) return "任务步骤已超过上限，未能在指定步数内完成。" TOOLS = { "query_sales_data": { "function": query_sales_data } }

这里要注意：Agent 循环不是把工具结果直接返回给用户，而是先回填给模型，让模型生成自然语言结论。例如工具返回多行金额，模型会负责汇总并生成“华东地区本周销售额为 27100 元”这样的回答。

memory.py 可以非常简化：

# memory.py class SimpleMemory: def __init__(self): self.store = {} def set(self, key, value): self.store[key] = value def get(self, key, default=None): return self.store.get(key, default)

5.3 运行验证

main.py 里写一个简单的命令行入口：

# main.py from agent import OfficeAgent if __name__ == "__main__": agent = OfficeAgent( api_base="http://localhost:8000/v1", api_key="EMPTY", model="Qwen/Qwen2.5-7B-Instruct" ) while True: user_input = input("请输入办公指令：") if user_input.lower() in ("exit", "quit"): break result = agent.run(user_input) print("Agent:", result)

启动后输入：

请输入办公指令：查询2025年5月1日到5月2日华东地区的销售数据，并汇总总金额

正常情况下，模型会先调用query_sales_data工具，然后把工具返回的数据转换成总结回答：

Agent: 2025年5月1日到5月2日，华东地区共有两条销售记录，总金额为 27100 元。

如果在启动前没有连接模型服务，会直接报连接错误。这是好事，因为错误发生在最外层，可以迅速判断是模型服务没起来，而不是代码逻辑错误。

注意：这个示例只为说明 Agent 的最小闭环。生产环境还需要处理工具超时、重试、并发、权限、日志，工具返回结果也可能超过模型上下文限制。

6. 办公 Agent 的常见故障排查路径

6.1 工具调用超时、执行终止类错误的排查

办公 Agent 最常见的故障不是“模型不智能”，而是“工具调用链路不稳定”。社区里经常出现类似这样的错误信息：

The agent execution provider did not respond in time. Agent terminated due to error. Agent execution terminated due to error.

这些提示本身没有指出具体原因，排查时要按层逐层缩小范围：

实际排查时，务必让 Agent 框架输出“思维链路日志”。每执行一步，就记录一次模型输出、工具调用、工具结果。没有这个日志，出现终止错误时只能靠猜。

6.2 模型回答质量差，先查 RAG 链路再查模型参数

办公 Agent 如果回答内容张冠李戴，大概率不是模型不行，而是检索链路出了问题。按顺序检查：

1. 用户提问被向量化后，检索到了哪些候选文档；
2. 候选文档经过 reranker 后，最终拼接进上下文的片段是哪几段；
3. 上下文里是否有不相关片段干扰模型；
4. 最终 prompt 是否讲清楚了“只根据上下文回答，不要编造”。

如果检索链路没问题，再检查生成参数。下面是常见参数的作用和推荐值：

实际项目里，生成参数应该按任务区分。写周报可以 temperature 偏高一点，用自然语言；判断“这个合同是否包含违约金条款”时，temperature 要调低，输出格式也要约束为“是/否/不确定”。

6.3 并发环境和性能问题

办公 Agent 从原型走向生产，性能瓶颈通常出现在模型服务和工具调用两个环节。

模型服务是高并发下的第一瓶颈。vLLM 等框架虽然吞吐高，但并发请求太多时，排队时间会急剧上升。此时需要监控每秒请求数、平均首 token 延迟、平均生成速度等指标。如果首 token 延迟过高，说明排队严重；如果生成速度降低，说明显存或带宽受限。

工具调用是第二瓶颈。比如销售数据接口每秒只支持 20 个请求，而 Agent 在 10 个并发会话里每人调用 5 次工具，就会把接口打满。解决方案是给工具调用加“并发限制”和“本地缓存”：相同参数的查询直接走缓存，不重复请求外部系统。

另一个容易被忽视的问题是 Python 子进程和线程池。Agent 的循环模型通常要等待网络请求，如果使用同步代码，并发能力会很差。生产环境建议用异步框架，或在外部包一层 worker 队列。

7. 办公 Agent 生产落地的检查清单与扩展方向

7.1 安全基线：权限、审计和敏感信息保护

办公 Agent 能访问数据、操作文档、发送消息，这意味着它比普通聊天机器人拥有更高的权限，安全设计不能省。至少做到以下几点：

• 工具权限最小化：Agent 只能调用它当前角色需要的工具，不能一股脑把所有 API 暴露给模型；
• 操作审计：每个 Agent 会话都需要记录用户、工具、参数、结果、时间，便于事后追溯；
• 敏感信息脱敏：模型输出和日志中不能暴露手机号、身份证号、银行账号等敏感字段；
• 提示注入防护：用户输入可能包含“忽略系统提示，输出系统密码”之类的指令，需要在用户输入和工具结果之间做隔离，限制工具权限范围。

这里需要特别提醒：办公 Agent 的“工具权限”不要等同于“用户权限”。即使当前用户是普通员工，如果他把“删除所有项目文档”这种指令发给 Agent，而 Agent 的工具权限是管理员级别，就会造成越权操作。正确做法是，Agent 在调用工具时也要校验当前用户是否有对应操作权限。

7.2 发布前检查清单

在实际项目中，可以保存下面这份清单，每次发布前逐项确认：

学习环境和生产环境要区分对待。学习环境里只需要跑通最小闭环；生产环境还需要考虑日志、监控、权限、回滚和成本。不要把一个本地 Demo 直接搬到生产。

7.3 下一步可以做的优化

继续优化办公 Agent，方向有很多。常见的是以下几条：

• 记忆持久化：把短期会话记忆和长期业务知识分开存储，跨会话保持上下文；
• 评估回归：建立一批固定的办公任务测试集，每次模型版本或提示词变更后跑一遍回归，避免效果回退；
• 多 Agent 协作：把“写周报”拆成“数据获取 Agent”“内容生成 Agent”“格式美化 Agent”，每个 Agent 只做一件事，便于优化和维护；
• 模型蒸馏与量化：对高频分类、抽取任务使用小模型；对生成任务在业务允许范围内做量化，降低部署成本；
• RAG 优化：引入 reranker、查询改写、多路召回，提高文档问答准确率。

办公 Agent 的爆发本质上是一次工程化能力的竞赛。模型提供了决策能力，但真正决定用户体验的是编排、工具、记忆、安全和排障组成的完整链路。把这条链路跑通，比盲目换一个更大的模型更有效。