企业级 Agent 怎么设计？一次面试后的系统性思考
前段时间参加了一个面试，聊到"你会怎么设计一个企业级 Agent 产品"。我当时讲了一些，回来越想越觉得值得梳理一遍。
结论先说：企业级 Agent 的核心不是模型，是工具（Tool）的设计。LLM 只是大脑，真正决定 Agent 能做多少事的，是你给它接了多少可靠的手和眼睛。而这些工具，按照服务对象不同，大致可以分三个方向——对外、对内、对个人。
对外：把发布流程变成一行指令
"对外"指的是企业向外部世界输出内容的能力：官网、博客、产品发布、公众号……这些事情看起来简单，但实际上每个渠道都有自己的格式要求、认证体系和发布限制。
我自己的发布链路大概是这样的：
- 代码 & 产品：用
ghCLI 推送 GitHub Release，打 tag，生成 changelog - Blog：本地用 Zola（SSG 框架）写 Markdown，
deploy.shbuild 后推到 GitHub，触发 Webhook 通知 ECS 上的 Nginx 拉最新版本 - 公众号：通过公众号开放平台拿 AppId/Secret，把 Markdown 转成符合规范的富文本 HTML（公众号不支持 CSS/JS，必须内联样式），调接口推草稿，最后手动点发布
这些如果全部打包成 Agent 可调用的 Tool，配上一个简单的 Orchestrator，"一键发布"就真的是一行自然语言指令的事。
趋势层面：多渠道分发会越来越成为企业的标配需求。不同平台的内容格式、审核规则、API 鉴权方式各不相同，这正是 Agent 最擅长处理的"规则繁多但逻辑固定"的任务。相比人工切换后台，Agent 的优势不是"更聪明"，而是永远不会忘记格式规范。
对内：把公司的知识变成可检索的资产
这是企业 Agent 最硬核、也最有商业价值的方向。
每家公司都有大量沉睡的内部文档：产品手册、会议纪要、技术规范、销售报告……大部分从来没有被有效利用过。对内 Agent 的核心任务，就是把这些内容变成可以被 LLM 语义检索的知识库——也就是所谓的 企业 RAG（Retrieval-Augmented Generation）。
难点不在 RAG 本身，在于文件格式的多样性。从易到难排个序：
| 格式 | 处理思路 |
|---|---|
.md / .txt | 直接按标题或固定 chunk_size（512~1024 token）分块 |
.docx | python-docx 提取段落和表格，映射为 Markdown 再分块 |
.xlsx | 行序列化：每行转成自然语言句子，如"产品: X, 价格: Y, 库存: Z"，整行作一个 chunk |
.pptx | python-pptx 按幻灯片分块，图片内文字需要 OCR |
.pdf | 原生 PDF 可直接提取文字层；扫描件 PDF 必须先走 OCR 流程 |
| 3D 模型 / CAD | 最复杂，需要多模态转换后再做 RAG，目前仍是工程难题 |
处理完成后，用 FastEmbed 生成向量，存入 Qdrant，再把搜索接口封装成 Agent 可调用的 Tool。
原理层面有一个容易被忽视的点：向量检索在语义相似度上表现好，但对精确关键词（如型号、编号、人名）容易失效。生产级的企业 RAG 通常需要混合检索（Hybrid Search）——把向量相似度和 BM25 关键词检索的结果融合排序（RRF 算法），才能覆盖两类查询场景。
趋势层面：RAG 从 2024 年以来被讨论得最多，但真正落地的案例里有一个共识——数据质量远比模型选型重要。一个清洗干净、分块合理的知识库，配上普通的 embedding 模型，效果往往好过用顶级模型去检索一堆乱七八糟的原始文档。垃圾进，垃圾出，LLM 无法拯救烂数据。
对个人：Agent 网络的雏形
这个方向最有意思，也是目前最前沿的部分。
"对个人"不只是给员工用，更准确的说法是：让 Agent 能够代表个人或组织与外部世界交互。分两类：
编程辅助
这个不用多说，所有 LLM 都会。尤其是当红炸子鸡 Claude Code, 已经把这件事做得很成熟了。
通信与协作
这里才是真正有意思的部分，可以再拆成两类：
1. Agent to Agent（A2A）
当两个 Agent 需要协作时，如何互相发现、互相理解对方的能力？Google 提出的 A2A 协议给出了一个方向：每个 Agent 发布一张 Agent Card，描述自己是谁、能做什么、支持哪些输入输出格式。陌生 Agent 之间先交换 Card 完成握手，再协商任务。
这本质上是在做 Agent 的服务发现，类似微服务架构里的 Service Registry，只不过注册的不是接口，而是能力描述。
即时通讯层面，Slack MCP 是个不错的参考起点——不需要自己重新造一套消息总线，接入现有的 MCP Server 就能让 Agent 在已有的协作工具里发送和接收消息。
2. 对接传统软件（微信等）
企业内部最常用的通讯工具往往还是微信或企业微信。让 Agent 能"发微信"，常规做法是：让对方关注公众号或企业微信账号，通过官方 API 下发消息。
但这有明显限制：需要对方主动关注，消息格式受限，无法做到真正的双向自然语言对话。
我最近在研究更通用的方式，如果有进展，后面可能会公布。
趋势层面：2025 年开始，Agent 通信协议正在快速标准化。MCP（Model Context Protocol）解决了"Agent 如何调用外部工具"的问题；A2A 在解决"Agent 如何与另一个 Agent 协作"的问题。这两层协议加起来，构成了一个多 Agent 协作网络的基础设施雏形——类似当年 HTTP 和 TCP 对互联网的意义。
一个底层原则：工具先行，模型后行
回到最开始的问题：企业 Agent 怎么设计？
我的答案是：先想清楚要给 Agent 接哪些工具，再考虑用什么模型。
LLM 的推理能力在主流模型之间差距越来越小，但一个 Agent 能不能可靠地完成任务，70% 取决于工具的设计质量：
- 工具的粒度够不够细（一个工具做一件事）
- 工具的描述够不够准确（LLM 靠描述决定要不要调用它）
- 工具的返回值够不够结构化（LLM 需要解析结果来决定下一步）
把这三件事做好，一个普通模型也能跑出令人满意的 Agent；把这三件事做烂，换最贵的模型也救不回来。
企业级 Agent 落地，其实就是有了大模型辅助的软件工程设计。