面向动手做企业智能体的同学。我们在西南做实体行业的 AI 落地，这篇以一个"消费品类企业的客服与线索智能体"为贯穿案例，讲清楚在火山引擎方舟（Ark）模型服务、扣子 Coze 的智能体编排、HiAgent 企业级中台与 AgentKit 这条生态里，一个垂直行业 Agent 具体是怎么实现的：知识怎么挂、工具怎么注册、高风险动作怎么拦、业务系统怎么接。文中产品能力以火山引擎官方文档为准，不虚构配额。
1. 案例与边界：先定义这个 Agent 到底干什么
案例企业有大量产品资料（规格、工艺、活动政策、物流与售后 FAQ），咨询量大、重复问题占比高，线索散落在多个内容渠道。我们没有一上来做"全能数字员工"，而是把第一期边界收得很紧：
- 能答：只依据企业知识库回答产品与售后问题，答案带出处；
- 能办：查物流、查门店、留资建档、预约到店；
- 不能办：退款、改价、发券、改投放预算——一律转人工或生成待审批单；
- 不碰：诊疗、投资建议这类强监管内容。
边界先行，是因为智能体的工程复杂度和风险，几乎都来自"它被允许做什么"，而不是"它会不会聊天"。
2. 整体架构：四层，各层用生态里最合适的能力
plaintext
┌─────────────────────────────────────────────┐
│ 渠道层：网页 / 公众号 / 企微 / 抖音私信与客服 │
├─────────────────────────────────────────────┤
│ 编排层：扣子 Coze（提示词/工作流/插件/知识库） │
│ 复杂企业态由 HiAgent 纳管 │
├─────────────────────────────────────────────┤
│ 能力层：方舟 Ark 模型(对话) ＋ RAG 检索 ＋ │
│ 工具/插件(物流、CRM、工单、投放只读API) │
├─────────────────────────────────────────────┤
│ 业务层：CRM / 订单 / 工单 / OA审批 / 数据回流 │
└─────────────────────────────────────────────┘
分工逻辑是这样的：
- 方舟解决"模型从哪来"：豆包系列、DeepSeek 等模型通过统一的推理接入点（endpoint）调用，按 token 计费、模型持续迭代。应用侧只认一个接入点，模型升级和切换在方舟控制台完成，业务代码不动。
- 扣子 Coze解决"怎么快速编排"：知识库、提示词、插件（工具）、工作流可以可视化搭起来，第一期的客服与留资链路主要在这里实现，适合快速验证。
- HiAgent解决"企业级治理"：当需要多模型纳管、多知识库按部门隔离、统一权限、私有化部署和完整的开发—评测—发布—运维生命周期时，把资产收敛到 HiAgent 这类企业 AI 中台上。Coze 开源版等智能体资产也可纳入统一标准管理。
- AgentKit面向需要快速构建生产级智能体应用的场景，提供更成体系的开发与部署支撑，适合在验证完成后加速工程化。
这套组合不是一开始就全上。真实顺序是：方舟 API + 扣子跑通原型 → 沉淀知识与评测 → 需要企业级管控时引入 HiAgent/AgentKit，与投入规模匹配，不返工。
3. 知识库：垂直行业问答的地基
行业问答 80% 的 badcase 不在模型，在知识。我们的处理流程：
- 资料治理：产品手册、价格政策、售后条款先清洗去重，区分"对外可答"和"内部可见"，这一步直接决定后面的权限边界；
- 结构化切片：按标题、条款、FAQ 条目切，价目表、规格表单独处理成结构化条目，切片间保留重叠，杜绝按固定字数硬切；
- 挂库与召回：在扣子知识库里配置分段与召回策略，问答时只从授权的知识库里取；
- 强约束生成：系统提示词里写明"仅依据知识库回答，无相关内容时明确告知并引导人工，回答标注引用来源"。
一个可以直接用的系统提示词骨架：
text
你是某品牌官方咨询助手，只能依据【知识库】中的资料回答。
规则：
-
知识库没有的内容，明确说"暂时没有查到相关信息"，并引导转人工，不得推测；
-
涉及价格/活动/库存，必须引用知识库条目，不使用记忆中的数字；
-
不承诺退款、赔偿、发货时间等知识库未授权的内容；
-
用户留下联系方式或表达购买意向时，调用留资工具；
-
退款、投诉、改价类诉求，不自行处理，生成转人工工单。
上线前我们准备了 30 条真实问法做评测集，覆盖"能答的、容易混的、知识库里没有的"三类，每次调分段或换模型都回归命中率和幻觉率。
还有一点经验：行业资料里价格、活动政策变化最频繁，我们给这类条目额外打上"生效时间"标签，过期内容不进召回，避免智能体拿着上一季的政策回答这一季的客户。召回侧也没有只依赖向量相似度，对"门店、订单号、型号"这类精确实体走关键词/结构化查询，再和语义召回结果合并，准确率比纯向量更稳。
4. 工具注册：把查物流、留资变成 Agent 可调的插件
Agent 能办事，靠的是工具。扣子的插件机制允许把内部 API 封装成工具供模型调用；工具描述和入参定义对齐 function calling 的 JSON Schema，模型据此决定"调不调、怎么调"。以留资为例：
json
{
"name": "crm_create_lead",
"description": "当客户留下手机号或明确表达购买/到店意向时，在CRM创建线索",
"parameters": {
"type": "object",
"properties": {
"name": {"type": "string", "description": "客户称呼，未知可留空"},
"phone": {"type": "string", "description": "客户手机号，必填"},
"intent": {"type": "string", "description": "意向产品/服务"},
"source": {"type": "string", "description": "会话来源渠道，如公众号、抖音、网页"}
},
"required": ["phone", "intent", "source"]
}
}
工具背后的服务端实现（脱敏示意），关键不是能写库，而是校验、幂等和分级：
python
def crm_create_lead(params: dict) -> dict:
if not is_valid_phone(params.get("phone")):
return {"ok": False, "msg": "手机号格式异常，已请客户重新确认"}
if crm.exists_today(params["phone"], params["source"]):
return {"ok": True, "lead_id": crm.latest_id, "dedup": True}
lead = crm.create(
phone=params["phone"], name=params.get("name", ""),
intent=params["intent"], source=params["source"],
)
if lead.score >= THRESHOLD:
notify_staff(lead)
return {"ok": True, "lead_id": lead.id}
工具我们按风险分三级管理：只读类（查物流、查门店、查投放报表）直接放行并留痕；写入类（建线索、建工单）参数校验 + 幂等；不可逆/涉钱类（退款、发券、改价、启停投放计划）不开放为 Agent 可执行工具，只提供"生成申请"的工具，走企业 OA 审批，人点确认后由系统执行。投放数据 API 只给只读权限，Agent 能做的是汇总消耗与线索质量、给素材建议，而不是替人动账户。
5. 核心编排：工作流比"自由发挥"可靠
多步任务我们优先用扣子的工作流显式编排，而不是让模型在一个大 prompt 里自由决定全流程。一个"咨询 → 留资"链路的编排伪代码：
text
START 用户消息
├─ 意图识别(方舟模型)
│ ├─ 产品/售后咨询 → RAG检索 → 带引用回答
│ │ └─ 用户追问 → 回到检索（带上会话记忆）
│ ├─ 留资/购买意向 → 信息补全槽位(姓名? 手机? 意向?)
│ │ └─ 槽位齐全 → 调 crm_create_lead
│ │ └─ 成功 → 告知"已安排顾问联系"
│ ├─ 查物流 → 校验订单归属 → 调 logistics_query（只读）
│ └─ 退款/投诉/改价 → 生成工单 → 转人工队列（不执行）
└─ 命中敏感/兜底规则 → 礼貌转人工
END（全程写 trace：意图、召回条目、工具、入参出参）
两个编排细节值得说：
- 槽位填充要多轮确认。 手机号这类关键信息，模型听错一位就是无效线索，我们要求复述确认后再调写库工具。
- 每一步可追踪。 意图、命中的知识条目、调用的工具和入参出参全部落日志。线上出 badcase 时能完整回放，而不是对着一句错误回答猜原因。这也为后面的评测回归和效果复盘提供了原料。
6. 接业务系统与数据回流："闭环"的工程含义
这个智能体真正接进经营链路，体现在三处对接：
- 渠道对接：内容平台、公众号、企微等渠道的消息经各自开放接口接入，统一进编排层，线索带来源标记；
- 系统对接：留资写 CRM、售后写工单系统、高意向触发企微提醒，人工销售接手的是一条信息完整的线索，而不是一句"有人问价"；
- 回流对接：会话与线索结构化入库——哪些问法答不上来（补知识库）、哪些工具调用失败（修接口）、哪个渠道进来的线索意向高（反哺内容与投放策略）。所谓"智能体做完还能帮着跑流量"，工程上就是这条"内容触达 → Agent 承接 → CRM 转化 → 数据回流"的通路，而不是一句营销承诺。
7. 上线前的检查项
- 知识库按内外权限隔离，提示词强制引用与兜底，评测集跑出基线；
- 工具白名单 + 最小权限服务账号，写操作幂等，涉钱动作全部人工确认；
- 方舟接入点信息、插件密钥走密钥管理，不硬编码进工作流；
- 全链路 trace、超时重试、限流降级与转人工兜底齐备；
- 约定知识更新、badcase 周回归和业务人员培训机制——模型和产品文档会持续迭代，智能体不是交付即终点。
8. 小结
垂直行业智能体的实现路径并不神秘：用方舟统一模型供给，用扣子快速完成知识库与工具编排，用 HiAgent/AgentKit 承接企业级治理与工程化；真正的门槛在知识治理、工具分级、显式编排和业务系统对接这些"不性感"的环节。把 Agent 的权限关在笼子里、把每一步都留痕可复盘，它才敢被放到真实客户面前。
作者：昆明一支企业 AI 落地团队（奇崛 AGI 研究院），做大模型部署、RAG、行业 Agent 与企业内训，并在火山引擎、腾讯云、阿里云、智谱等生态上落地。本文为通用工程实践，文中涉及的方舟、扣子、HiAgent、AgentKit 具体能力与配额请以火山引擎官方文档为准。