用讯飞星辰Agent搭建并发布一个知识库问答智能体

讯飞星辰Agent 是科大讯飞推出的智能体开发与运行平台，核心入口是 AStudio 工作台。它把大模型能力、知识库、外部 API 调用和流程编排放在同一个可视化界面里，让开发者不必从零写对话管理代码，就能把一个想法做成可上线运行的智能体。平台面向企业级场景，内置调试评测与权限、内容审核机制，适合智能客服、内部知识问答、业务助手、流程自动化等需求。如果你手上有一批企业文档，希望用户能用自然语言提问并拿到基于文档的回答，这篇教程就是按这条路径展开的。站内也有该工具的条目页：讯飞星辰Agent，可以先看概况再回到本文动手。

需要说明的是，本文讲的是通用做法与流程顺序，不涉及任何具体账号的实测结果。平台的功能、配额、计费方式会随时间调整，涉及价格与额度的部分请以官网当前信息为准。

准备工作

动手之前，先把下面几件事确认清楚，能省掉后面大量返工。

账号与入口

• 一个可用的讯飞账号。平台使用讯飞账号登录，没有账号需要先注册。
• 确认账号所属的组织或团队。企业场景下智能体往往需要多人协作，提前确认自己在该组织中的角色，避免建好项目后没有发布权限。
• 浏览器环境。平台是网页版工作台，用桌面浏览器访问即可，不需要本地安装客户端。

明确智能体要解决的问题

这一步经常被跳过，但它直接决定后面知识库怎么切、工具怎么定义。建议先用一句话写清楚：谁在什么场景下问什么问题，期望得到什么形式的回答。例如「一线客服在接待用户时查询退换货政策，期望得到条款原文加一句通俗解释」。目标越具体，调试阶段的判断标准就越清晰。

整理知识库素材

• 把要接入的文档收集齐，包括制度文件、产品手册、FAQ、操作指引等。
• 去掉明显过期、互相矛盾的版本，同一主题只保留一份权威版本。知识库里的冲突内容会直接反映到回答里。
• 结构化数据（如表格形式的业务数据）单独归类，平台支持接入结构化数据，但它的使用方式与纯文本文档不同，最好分开管理。
• 检查文档里是否有不该对外暴露的内容。知识库一旦接入，相关内容就可能出现在回答中。

梳理需要调用的外部能力

如果智能体除了回答问题还要「做事」——查订单、建工单、查库存——需要提前准备好对应接口的地址、鉴权方式和参数说明。工具调用依赖外部 API，接口本身不通，编排做得再好也跑不起来。

操作步骤

下面按从零到发布的顺序展开。每一步都说明要做什么、在哪里做、以及做完之后应该看到什么结果。

第一步：登录并进入 AStudio 工作台

访问讯飞星辰Agent 官网，使用讯飞账号登录。登录后进入 AStudio 工作台，这里是智能体项目的管理入口，已创建的项目、模板入口和新建入口都在这一层。第一次进入时工作台是空的，属于正常现象。

第二步：创建智能体项目并选择基础模型

在工作台创建新的智能体项目。创建过程中需要为项目命名，并选择或配置基础模型。平台基于讯飞星火大模型提供语言理解与生成能力，模型选择会影响回答质量、响应速度和可用上下文长度。

选择模型时的几个判断依据：

• 任务复杂度。需要多步推理、长文档理解的任务，对模型能力要求更高；简单的意图识别和固定话术回复，用较轻的模型即可。
• 上下文长度。知识库问答往往要把检索到的文档片段塞进上下文，片段越长、条数越多，对上下文窗口的要求越高。
• 响应时延。面向终端用户的客服场景对首字延迟敏感，内部工具类场景相对宽松。

具体可选模型清单与各自的参数规格，以控制台当前展示为准。

第三步：编排对话流程

进入编排界面后，核心工作是定义这个智能体「怎么对话」。可视化编排采用拖拽式流程设计，把对话节点、判断分支、知识库检索、工具调用等组件连成一条可执行的路径。相比纯提示词写法，流程编排的好处是复杂逻辑可以被显式表达出来，后续维护和交接也更容易。

一个知识库问答智能体的典型编排结构：

1. 意图识别节点。判断用户这句话是要查知识、要办业务，还是闲聊。不同意图走不同分支。
2. 知识检索分支。调用知识库检索，拿到相关文档片段，再交给模型组织成回答。
3. 工具调用分支。命中业务操作意图时，调用对应的外部 API，把返回结果转成自然语言。
4. 兜底分支。检索不到、工具报错、意图不明时，给出明确的引导话术，而不是让模型自由发挥。

编排时还要配置多轮对话管理。平台支持上下文记忆与对话状态跟踪，需要决定哪些信息在轮次之间保留（例如用户已表明的身份、已选中的订单号），哪些每轮重新获取。保留过多会让上下文膨胀并引入干扰，保留过少则用户每轮都要重复说明。

第四步：接入知识库

知识库集成是这类智能体的核心能力。平台支持接入企业文档与结构化数据，用于实现基于私有资料的精准问答。接入时通常需要完成以下动作：

• 创建知识库并上传文档。上传后平台会对文档做解析与切分，切分粒度影响检索命中率：切得太碎会丢失上下文，切得太大会引入无关内容。
• 为知识库配置检索参数，例如每次召回多少条片段。召回条数多，覆盖面广但上下文压力大；条数少，精准但容易漏。
• 在编排中把知识库检索节点接到对应分支上，并明确告诉模型「优先依据检索内容回答，检索不到时说明无法回答」。这条约束能显著减少编造。

结构化数据的接入方式与文档不同，通常用于精确查询类问题（如按条件筛选记录），在编排中更适合走工具调用分支而非语义检索分支。

第五步：定义工具调用

工具调用让智能体能够执行实际业务操作。定义工具时需要提供：

• 工具名称与用途描述。描述要写清楚「什么时候该用这个工具」，模型依据描述决定是否调用。
• 接口地址与请求方式。
• 入参定义，包括参数名、类型、是否必填、取值范围。参数定义越严格，模型传错参数的概率越低。
• 鉴权信息与返回结果的解析方式。

工具返回的内容通常不能直接展示给用户，需要在编排里加一步转换，把结构化结果整理成一句人话。同时要为工具调用失败准备分支：接口超时、返回空结果、鉴权失效，都应该有对应的提示，而不是把错误信息原样抛给用户。

第六步：模拟对话调试

编排完成后进入调试环节。平台提供模拟对话能力，可以在不发布的情况下与智能体交互，观察它在各类输入下的表现。调试阶段建议按下面的顺序推进：

1. 正常路径。用最典型的几个问题测试，确认能检索到正确文档并给出准确回答。
2. 边界问题。问一些知识库里没有的内容，确认智能体明确表示无法回答，而不是编造。
3. 表述变体。同一个问题换几种问法，包括口语化、错别字、简称，观察检索是否稳定。
4. 多轮场景。连续追问、中途切换话题、指代前文（「那这个呢」），检查上下文管理是否合理。
5. 工具路径。触发工具调用，检查参数是否正确、返回结果是否被正确转述、失败分支是否生效。

每次调整参数后重新跑一遍上述用例，记录哪些问题解决了、哪些是新引入的。平台内置的评测工具可以帮助把这一过程做得更系统，具体评测项的配置方式以控制台为准。

第七步：发布并集成到业务系统

调试通过后即可发布智能体。发布意味着它从工作台里的草稿变成可被外部调用的服务，之后可以集成到业务系统中投入使用，例如嵌入客服工作台、接入内部 IM、作为独立页面提供给用户。

发布前确认三件事：

• 权限配置是否正确。哪些角色可以调用、哪些人可以修改配置，需要区分开。
• 内容审核是否开启。面向外部用户的场景，审核机制是必需项。
• 版本管理是否清晰。发布后如果继续修改，要能区分线上版本和开发版本，避免调试中的改动直接影响线上用户。

一个完整示例

下面用一个具体场景把上面的步骤串起来：为一家电商公司做一个「售后政策问答助手」，面向一线客服，回答退换货、运费、保修相关问题，并能查询某个订单的当前售后状态。

场景定义

使用者是一线客服，问题集中在售后政策条款和具体订单状态两类。回答要求：政策类问题给出条款依据，订单类问题给出当前状态和下一步操作建议。

素材准备

• 《退换货政策》文档一份，含七天无理由、质量问题、特殊品类例外三部分。
• 《运费规则说明》一份。
• 《保修条款》一份。
• 订单售后状态查询接口一个，入参为订单号，返回状态码与状态描述。

搭建过程

1. 登录后进入 AStudio 工作台，新建智能体项目，命名为「售后政策问答助手」。
2. 选择基础模型。由于需要理解较长的政策条款并做多轮追问，选择上下文能力较强的模型；具体型号以控制台当前可选项为准。
3. 创建知识库，上传上述三份文档。切分粒度按条款段落处理，保证每条片段能独立表达一个完整规则。
4. 在编排界面搭建主流程：入口先做意图识别，分为「政策咨询」「订单查询」「其他」三类。
5. 「政策咨询」分支接知识库检索节点，召回若干条相关片段，交给模型组织回答，并在提示中约束「仅依据检索内容作答，无依据时说明未查到相关规定」。
6. 「订单查询」分支接工具调用节点，定义工具「查询订单售后状态」，入参为订单号（字符串，必填）。若用户未提供订单号，流程先追问再调用。
7. 「其他」分支给出兜底话术，引导用户描述具体问题。
8. 配置多轮上下文：保留用户已提供的订单号，保留最近若干轮对话内容，其余不长期保留。

调试用例

用例	输入	期望表现
政策直问	「七天无理由退货有什么条件？」	引用政策文档中的条件条款，逐条列出
政策变体	「买回来不想要了能退吗」	识别为政策咨询，给出无理由退货的适用条件
知识库外问题	「你们支持以旧换新吗？」	明确说明未查到相关规定，建议转人工
订单查询	「帮我查下订单 123456 的售后进度」	调用工具，返回当前状态与下一步建议
缺参数	「我的售后到哪一步了」	追问订单号，拿到后再调用工具
多轮追问	先问政策，再问「那运费谁出」	结合上一轮语境，给出运费承担规则
工具异常	订单号不存在	提示未查询到该订单，请核对后重试

发布

全部用例通过后发布智能体，配置调用权限为客服团队可用，开启内容审核，然后集成到客服工作台中。上线后持续收集未命中的问题，定期补充进知识库，形成迭代闭环。

注意事项

知识库质量决定回答质量

检索增强类智能体的上限由知识库决定。文档过期、版本冲突、切分不当，都会直接表现为回答错误。上线前应安排业务方对知识库内容做一次确认，上线后建立定期更新机制。

切分粒度需要实测调整

文档切得太碎，单条片段缺少上下文，模型拿到后无法理解；切得太大，一次召回就占满上下文，还会引入无关内容。这个参数没有通用最优值，需要针对自己的文档类型在调试中反复调整。

明确约束「无依据不回答」

如果不加约束，模型在检索不到内容时倾向于凭常识作答，在政策、合规、医疗等场景中这是严重风险。应在提示中显式要求「仅依据检索内容回答」，并在编排中保留兜底分支。

工具调用的失败路径要单独设计

外部 API 会超时、会返回空、会因鉴权过期而失败。这些情况如果没有对应分支，用户会看到原始错误信息或长时间无响应。每个工具节点都应配置失败提示与降级方案。

上下文记忆要设上限

多轮对话中无限累积历史会让上下文迅速膨胀，既增加成本也降低回答准确性。应明确哪些信息需要跨轮保留，其余按轮次窗口截断。

权限与审核是发布前的必检项

平台提供权限管理与内容审核机制，用于满足企业级应用对稳定性与合规性的要求。面向外部用户发布时，审核必须开启；面向内部发布时，也要确认调用范围与配置修改权限已经分离。

区分开发版本与线上版本

发布后继续优化是常态。修改配置时应确保不影响线上正在服务的版本，验证通过后再切换。具体版本管理能力以控制台当前提供的方式为准。

易变信息以官网为准

模型型号、可用功能、调用配额、计费方式都可能调整。本文不给出具体数字，实际使用前请查阅官网当前信息，避免按旧数据做容量规划。