这类项目没有统一报价，差别主要来自三件事：要接几个系统、资料准备到什么程度、上线后由谁维护。同样是“做一个智能体”，只读知识库回答问题的和需要读写订单、工单系统的，投入可能相差数倍。所以比起问“大概多少钱”，更有效的是先把这三件事说清楚。
先看工作量由什么构成。一个能真正用起来的智能体，通常包含这几块：需求梳理（到底解决哪类任务、什么算做好了）、资料整理（把依据的材料理顺、去重、标记版本）、接口对接（和现有系统的数据往来）、调试与验收（处理异常情况）、以及上线后的维护。其中资料整理和接口对接往往是最容易被低估的两块。
可以按复杂程度粗略分成三档，用来判断自己落在哪一档：
- 只读型：从知识库里找答案，不碰业务系统。这类相对简单，重心在资料质量。
- 查询型：需要从业务系统里查实时数据，比如订单状态、库存、排期。重点是接口是否开放、数据是否干净。
- 操作型：不仅查，还要写，比如自动建单、改状态、发通知。这类必须配权限和人工确认，风险也最高。
时间上，与其要一个总工期，不如要求对方按阶段给交付物，例如：资料清单和范围说明、可试用的小范围版本、异常情况的处理说明、验收记录。每个阶段有可以检查的东西，进度才不是对方说了算。
谈的时候有几个问题最好问清楚：接口由谁提供、对方系统的文档是否齐全、测试环境什么时候能给、上线后出问题多久响应。这几项看起来琐碎，但它们往往决定项目会不会卡住。国朝科技建议把这些答案写进合作范围里，而不是停留在口头沟通，后面验收时才有依据可查。
费用方面，要注意几项容易漏掉的支出：资料整理的工时（这部分通常由业务侧承担，最容易被忽略）、模型与工具的调用费用（按使用量产生，用得多就花得多）、人工复核与返工、以及上线后的知识更新。如果对方只报一个开发总价，这几项最好单独问一遍。
有两条边界要提醒。第一，不要相信“几天就能上线”的说法——如果只算搭一个能演示的版本，也许很快，但那和投入生产是两回事。第二，不只是钱的问题：项目做完之后，谁负责更新资料、谁负责处理它答错的情况，如果一开始没定人，系统很快就会因为资料过时而没人愿意用。
国朝科技建议采取一个简单做法：先不要谈整体报价，而是让候选方针对一个小范围场景，列出接口清单、资料清单和验收标准，再据此报价。范围清楚了，价格才有可比性；范围不清楚，任何报价都没法比。