企业官网建设流程全解析

1. 为什么“30个智能体”不是噱头，而是AI工程师的能力分水岭

过去两年，我参与过不少大语言模型落地项目，从最初的“套壳问答”到后来的RAG检索增强，再到如今真正让模型自主调用工具、拆解任务、闭环决策的智能体系统。说实话，能跑通一个Demo的工程师很多，但能设计出在医疗、金融这类高约束场景下稳定运行的智能体，数量骤减。原因不复杂：智能体不是“更长的提示词”，而是一套融合了任务规划、工具调用、记忆管理、异常恢复和领域知识注入的微型系统工程。

标题里提到的“30个智能体”，我理解它不是一个硬性数字指标，而是一种能力图谱的隐喻——就像后端工程师要熟悉几十种设计模式，AI工程师也需要在头脑中储备足够多的智能体范式。医疗场景下的“分诊智能体”和金融场景下的“反欺诈调查智能体”，底层都依赖LLM，但它们的决策链路、工具集、失败回滚策略完全不同。如果你只会写一个“你是一个 helpful assistant”的系统提示，那连第一个智能体都算不上合格。

这篇文章面向的读者很明确：已经能调用LLM API、写过基础提示词，但面对“让模型自主完成多步决策”时感到无从下手的AI工程师。我会从智能体的核心构件讲起，拆解医疗与金融两个垂直领域的真实设计差异，给出可复现的搭建步骤，并分享我在并发、幻觉抑制、工具编排上踩过的坑。全文不涉及任何敏感工具或违规内容，只聚焦工程实现。

提示：本文讨论的“自主决策”指在预设工具边界和人工审核节点内的自动化，不意味着完全脱离监管的AI行为。

2. 拆开一个垂直领域智能体：四个必须自己写的核心模块

很多人一上来就问“用哪个框架”，LangChain、Dify、AutoGen还是自己撸？我的经验是：框架能帮你省掉30%的胶水代码，但剩下70%的领域逻辑，框架替不了你。在选型之前，先把智能体的四个核心模块想清楚，否则换什么框架都是换汤不换药。

2.1 任务规划器：把“帮我分析这份财报”翻译成可执行步骤

LLM本身不擅长长程规划，它擅长的是“给定上下文，预测下一个合理token”。所以任务规划器的本质，是用提示词工程加少量代码，把模糊的用户意图拆成有向无环图。比如用户说“帮我看看这家公司有没有财务风险”，一个合格的金融智能体不会直接让LLM写一段分析，而是先规划：

1. 提取公司实体和报告期
2. 调用财务数据接口获取三张报表
3. 计算流动比率、速动比率、资产负债率等指标
4. 与行业均值对比
5. 检索近期公告中的风险提示
6. 汇总生成结论并标注置信度

这个规划过程可以用Few-shot提示实现，也可以用一个轻量级的分类模型先判断意图类型。我实测下来，对于步骤数少于8步的任务，Few-shot加JSON schema约束的规划准确率能到85%以上；超过8步，建议引入递归拆解或人工预设模板。

2.2 工具调用层：别让模型直接碰数据库

这是最容易出安全事故的地方。我见过有团队让LLM生成SQL直接查生产库，结果模型被诱导生成了DROP TABLE。正确的做法是工具白名单加参数校验。每个工具是一个独立的函数，有明确的输入schema和输出schema，LLM只能选择工具并填充参数，不能执行任意代码。

以医疗场景为例，一个“检验报告解读智能体”的工具集可能包括：

注意最后一行：智能体必须知道什么时候“不决策”。在医疗和金融领域，把问题交给人类专家不是失败，而是设计的一部分。

2.3 记忆管理：短期上下文与长期知识要分开存

LLM的上下文窗口再大，也不能把所有历史对话和领域文档都塞进去。我的做法是分三层：

• 会话记忆：最近N轮对话，用滑动窗口或摘要压缩，存在Redis里，TTL设30分钟。
• 任务记忆：当前任务的中间结果，比如已计算的财务指标、已检索的指南片段，用JSON结构存在内存或临时表。
• 领域知识：向量化后的文档库，通过RAG按需检索，不常驻上下文。

这里有个坑：不要把向量检索结果直接拼到系统提示里。我见过一个金融智能体，每次对话都检索50条文档片段，导致上下文爆炸，响应时间从2秒涨到15秒。正确做法是先让LLM判断“是否需要外部知识”，需要时再检索，且限制返回Top-3片段。

2.4 异常恢复与置信度校准：智能体成熟的标志

一个只会往前跑的智能体是危险的。在金融反欺诈场景中，如果工具调用超时或返回异常，智能体应该能：

1. 重试一次（带退避）
2. 如果仍失败，切换到备用数据源
3. 如果备用也失败，生成“信息不足，建议人工复核”的结论，而不是编造数据

置信度校准更关键。LLM输出的“我认为”没有意义，你需要让它输出一个0到1的分数，并用历史数据校准这个分数。比如模型说置信度0.9，实际准确率只有0.6，那这个分数就是虚的。我的做法是定期用标注数据跑一遍，画出可靠性曲线，然后对分数做分段映射。

3. 医疗智能体的特殊约束：从“不能出错”倒推设计

医疗领域对智能体的要求和金融、电商完全不同。电商推荐错了，用户顶多不买；医疗建议错了，后果可能是不可逆的。所以医疗智能体的设计哲学是保守优先、可解释、强审核。

3.1 分诊智能体：症状采集的追问策略

分诊智能体的核心不是诊断，而是用最少的轮次采集到足够的信息，并正确路由。我设计过一个儿科分诊智能体，它的追问逻辑不是让LLM自由发挥，而是基于决策树加LLM润色。比如：

• 第一轮：主诉是什么？（发热、咳嗽、皮疹等）
• 如果主诉是发热：追问持续时间、最高体温、有无惊厥
• 如果持续时间超过3天且体温超过39度：标记为“建议24小时内就诊”
• 如果出现惊厥：直接标记“紧急”，触发人工介入

LLM在这里的作用是把结构化问题转成自然的追问话术，以及从家长的自由描述中抽取关键实体。决策逻辑本身是确定性的，不交给LLM。

3.2 检验报告解读：参考区间与个体差异的平衡

检验报告解读智能体最容易犯的错误是“一刀切”。比如肌酐值，成年男性和女性的参考区间不同，儿童和老人也不同。智能体必须能根据患者的人口学信息动态选择参考区间。

更复杂的是趋势解读。单次检验值正常不代表没问题，如果某指标连续三次上升，即使还在参考区间内，也可能需要提示。这要求智能体有时间序列分析能力，而不仅仅是单点判断。我的实现方式是：工具层返回历史检验值，规划器生成“计算变化率”的步骤，LLM只负责用自然语言解释变化趋势的临床意义。

3.3 用药咨询智能体：为什么我坚持加一道“药师审核”开关

用药咨询涉及剂量、相互作用、禁忌症，任何一个错误都可能致命。我设计的用药咨询智能体有一个硬性规则：任何涉及具体剂量的回答，必须经过药师审核才能发送。智能体可以生成草稿，可以检索说明书，可以提示“该药物与华法林合用需监测INR”，但不能直接给出“请服用XX毫克”的最终建议。

这个开关在工程上就是一个状态位：requires_pharmacist_review = true。当智能体检测到用户问题涉及剂量调整、特殊人群用药、超说明书用药时，自动置位，并把草稿路由到人工审核队列。这不是技术上的偷懒，而是对生命的敬畏。

4. 金融智能体的决策链路：在合规与效率之间找平衡

金融场景和医疗最大的不同是：很多决策可以量化，且允许一定误差。反欺诈模型误拦一笔交易，用户可以打电话解冻；但医疗误诊没有“解冻”按钮。所以金融智能体可以更激进地自动化，但必须满足合规审计要求。

4.1 反欺诈调查智能体：从规则引擎到LLM推理的融合

传统反欺诈靠规则引擎，比如“同一IP短时间多笔交易”触发警报。但规则引擎的误报率高，且无法处理新型欺诈模式。LLM智能体的优势在于能理解非结构化信息，比如商户名称的异常、交易备注中的可疑关键词、用户行为序列的语义异常。

我设计的反欺诈调查智能体工作流如下：

1. 规则引擎初筛，输出可疑交易列表
2. 对每笔可疑交易，智能体调用工具获取：用户历史行为、设备指纹、商户画像、地理位置
3. LLM综合这些信息，生成“欺诈可能性评分”和“理由”
4. 评分高于阈值：自动冻结并通知用户；评分中等：转人工复核；评分低：放行但记录

这里的关键是理由必须可审计。LLM不能只说“我觉得可疑”，而要输出“该交易与用户历史行为模式偏离度达3个标准差，且商户注册时间不足7天”。这些理由要写入审计日志，供监管检查。

4.2 财务报告分析智能体：指标计算与叙事生成的分离

财务分析智能体最容易出现的幻觉是编造数字。LLM对数字不敏感，你让它“计算流动比率”，它可能给你一个看起来合理但完全错误的值。我的解决方案是计算与叙事分离：

• 所有数值计算由Python函数完成，LLM只负责调用和解释
• LLM生成的报告中，每个数字必须标注来源（如“根据2024年Q3资产负债表”）
• 如果某个指标无法计算（数据缺失），智能体必须明确说“数据不足”，而不是估算

我实测过一个案例：让LLM直接分析一份PDF财报，它给出的净利润增长率与真实值偏差12%。改成“工具提取数字+Python计算+LLM解释”后，偏差降到0。在金融领域，可验证性比流畅性重要得多。

4.3 合规审查智能体：把监管条文变成可执行的检查清单

金融合规涉及大量条文，人工审查效率低且容易遗漏。合规审查智能体的思路是：把监管条文拆成原子化检查项，每个检查项对应一个工具调用或LLM判断。

比如“投资者适当性管理”可以拆成：

• 检查项1：客户风险测评是否在有效期内？（工具查询）
• 检查项2：产品风险等级是否匹配客户风险承受能力？（规则判断）
• 检查项3：销售过程是否有录音录像？（工具查询）
• 检查项4：是否存在误导性表述？（LLM分析对话记录）

每个检查项输出“通过/不通过/需人工确认”，最后汇总。LLM在检查项4中的作用是分析销售话术，识别“保本”“稳赚”等违规词汇。这种设计让智能体的决策边界非常清晰，也便于监管追溯。

5. 从零搭建一个领域智能体的实操路径

说了这么多设计原则，具体怎么动手？我以“金融财报问答智能体”为例，给出一个最小可行产品的搭建步骤。你不需要30个智能体同时开工，先跑通一个，再复制到其他场景。

5.1 环境准备与框架选型：为什么我最终选了轻量级方案

框架选型上，我试过LangChain、LlamaIndex、AutoGen和Dify。结论是：如果你的智能体工具集少于10个、流程相对固定，用原生Python加OpenAI SDK就够了。LangChain的抽象层在复杂场景下反而增加调试难度，AutoGen的多智能体对话在垂直领域容易发散。

我的最小依赖清单：

• Python 3.10+
• OpenAI SDK（或兼容接口的本地模型）
• Pydantic（用于工具参数校验）
• Redis（会话记忆）
• FAISS或Chroma（向量检索，可选）

如果你需要可视化编排，Dify是不错的选择，但要注意它的工具调用能力相对受限，复杂逻辑还是得写代码。

5.2 定义工具集：从“财报三张表”开始

先定义三个核心工具：

from pydantic import BaseModel, Field class GetFinancialStatement(BaseModel): company_id: str = Field(description="公司唯一标识") statement_type: str = Field(description="资产负债表/利润表/现金流量表") period: str = Field(description="报告期，如2024Q3") def get_financial_statement(company_id: str, statement_type: str, period: str) -> dict: # 实际实现：查询数据库或调用内部API # 返回结构化数据 pass

工具定义的关键是参数描述要足够清晰，因为LLM是根据描述来决定填什么值的。company_id的描述要说明格式，period要给出示例。我见过因为参数描述模糊导致LLM填错格式的案例，调试了半天才发现是提示词问题。

5.3 编写规划提示词：让LLM学会“先查再算后说”

规划提示词的核心是约束输出格式。我通常要求LLM输出JSON，包含steps数组，每个step有tool和params。如果不需要工具，则输出final_answer。

一个简化的提示词模板：

你是一个财务分析助手。根据用户问题，决定是否需要调用工具。 可用工具：get_financial_statement, calculate_ratio, search_announcement 输出格式：{"steps": [{"tool": "...", "params": {...}}]} 或 {"final_answer": "..."} 规则： 1. 涉及具体数字的问题，必须先调用工具获取数据 2. 计算比率时，先获取原始数据，再调用calculate_ratio 3. 不确定时，输出final_answer说明信息不足

这个提示词看起来简单，但规则3是最重要的。没有规则3，LLM会倾向于编造答案。

5.4 串联执行循环：处理工具返回与多轮规划

执行循环的逻辑是：

1. 调用LLM生成规划
2. 如果输出final_answer，结束
3. 如果输出steps，依次执行工具
4. 把工具结果追加到上下文
5. 再次调用LLM，判断是否需要继续规划
6. 设置最大轮次（我通常设5轮），防止无限循环

这里有个细节：工具返回结果要截断。如果工具返回一个巨大的JSON，直接塞回上下文会爆token。我的做法是只保留关键字段，或者让LLM先总结再继续。

5.5 加入人工审核节点：不是所有回答都直接返回

对于财报问答，如果用户问的是“这家公司能不能投资”，智能体不应该直接给建议。我的做法是设置一个敏感问题过滤器，检测到投资建议类问题时，返回“根据合规要求，我无法提供投资建议，但可以帮你分析财务指标”。这个过滤器可以用关键词匹配加LLM分类实现。

6. 并发、幻觉与工具编排：三个最容易翻车的地方

6.1 并发场景下的会话隔离与状态管理

当多个用户同时使用智能体时，会话状态必须隔离。我见过有团队把会话ID存在全局变量里，结果A用户的对话历史串到了B用户。正确做法是每个请求携带session_id，所有状态读写都基于session_id。

并发量上来后，还要考虑LLM API的速率限制。我的策略是：

• 对LLM调用做队列化，控制并发数
• 对工具调用做缓存，相同参数在短时间内不重复查询
• 设置超时和降级策略，LLM超时则返回“请稍后重试”

实测下来，单实例在4核8G的机器上，用队列控制并发，能稳定支撑50 QPS左右。再高就需要水平扩展了。

6.2 幻觉抑制：让智能体学会说“我不知道”

幻觉是LLM的固有特性，无法根除，但可以抑制。我的三板斧：

1. 强制引用：要求LLM在回答中标注信息来源，如“[来源：2024Q3利润表]”
2. 工具优先：涉及事实的问题，必须先调用工具，工具返回空则回答“未查询到”
3. 置信度阈值：LLM输出置信度，低于0.7的回答自动附加“以上分析仅供参考，请核实原始数据”

还有一个技巧：在系统提示中明确禁止推测。比如“如果数据不足，直接说明，不要根据常识推测”。这句话能减少大量幻觉。

6.3 工具编排的依赖管理：什么时候该并行，什么时候必须串行

工具调用不总是串行的。比如获取资产负债表和利润表可以并行，但计算流动比率必须等资产负债表返回。我的做法是让LLM在规划时标注依赖关系，或者用简单的规则引擎判断。

对于复杂依赖，我建议先串行跑通，再优化并行。过早优化并行会增加调试复杂度，而收益在低并发下并不明显。

7. 我在实际项目中积累的几条硬经验

第一条：智能体的价值不在于“全自动”，而在于“可中断”。一个能在关键时刻停下来问人的智能体，比一个闷头跑到黑的智能体有用得多。在医疗和金融场景，人工介入节点不是缺陷，是特性。

第二条：提示词版本管理比代码版本管理更重要。LLM的行为对提示词极其敏感，改一个词可能导致输出格式全变。我现在的做法是提示词存在数据库里，每次修改都有版本号和回滚机制，并且用A/B测试验证效果。

第三条：不要追求“一个智能体解决所有问题”。30个智能体的隐喻就在这里——每个智能体应该聚焦一个垂直场景，工具集不超过15个，规划步骤不超过10步。超过这个规模，拆成多个智能体协作，比一个巨型智能体更稳定。

第四条：测试集要覆盖“边缘案例”。正常问题谁都能答，真正考验智能体的是：数据缺失时怎么办？工具超时怎么办？用户问了一个完全无关的问题怎么办？我通常会构造50到100个边缘案例，每次提示词或工具变更后跑一遍回归测试。

第五条：日志要记录完整决策链路。不只是最终回答，还包括：LLM的规划输出、每次工具调用的参数和返回、置信度分数、是否触发人工审核。这些日志在排查问题时是救命稻草。我吃过亏，一个金融智能体偶尔给出错误比率，查了两天才发现是某个工具在特定参数下返回了缓存脏数据，而日志里只记了最终答案。

8. 从第一个智能体到第三十个：我的扩展路线图

如果你现在还没搭建过任何智能体，我建议的路线是：

第一阶段：单工具智能体。比如一个“天气查询智能体”，只有一个工具，跑通规划、调用、回答的完整链路。这个阶段的目标是理解LLM如何决定调用工具。

第二阶段：多工具串行智能体。比如“财报分析智能体”，3到5个工具，有依赖关系。目标是掌握规划提示词和执行循环。

第三阶段：带记忆和RAG的智能体。加入会话记忆和向量检索，处理多轮对话和知识问答。目标是理解上下文管理。

第四阶段：带人工审核和置信度的智能体。加入审核开关和置信度校准，面向真实业务场景。目标是理解安全边界。

第五阶段：多智能体协作。比如一个“投资研究团队”，有负责数据收集的智能体、负责分析的智能体、负责合规审查的智能体，通过消息队列协作。这个阶段我还在探索中，目前的体会是协作协议比单个智能体的能力更重要。

每过一个阶段，你对“智能体”的理解都会刷新一次。30个智能体不是目标，而是你在这条路上自然积累的能力图谱。等你真正搭建过十几个不同场景的智能体后，会发现底层模式是相通的，差异只在领域约束和工具集。

最后分享一个我最近在用的调试技巧：把智能体的决策过程用自然语言打印出来。不是给用户看，是给自己看。比如“用户问净利润，我决定先调用利润表工具，因为问题涉及具体数字；工具返回了数据，我决定调用计算工具算增长率；计算完成，我生成回答”。这个“内心独白”能帮你快速定位是规划错了、工具错了还是生成错了。比看JSON日志直观得多。