最近很多开发人员都在问我一个问题：智能体到底应该怎么开发？是不是接入一个大模型，再写一段提示词，让它自己决定下一步做什么，就可以了？
如果只是做一个演示，这样确实能很快做出效果。但如果要让别人真正使用，问题就没有这么简单了。智能体需要知道自己的任务是什么，什么时候需要调用工具，结果应该保存在哪里，发现证据不足时怎么处理，最后还要能够把过程和结果说清楚。
我最近做的科技文献智能服务平台里，有一个智能选题智能体。它的任务很明确：用户输入一个研究方向，系统帮用户查资料、看趋势、找研究空白，最后整理出几个可以继续讨论的候选题目。
下面我就用这个例子，站在开发者的角度，把智能体的开发过程讲简单一点。
一、先别急着接大模型，先说清楚要解决什么问题
开发智能体的第一步，不是选择模型，也不是先写提示词，而是把任务说清楚。
比如“帮我做科研选题”这个说法就太大了。我们需要继续往下问：用户会输入什么？系统最后要输出什么？中间需要查哪些资料？哪些结果必须有依据？什么时候需要让用户补充信息？
在这个项目里，我把任务定义成了这样：用户输入一个研究方向和一些限制条件，智能体经过文献检索和分析以后，输出候选题目、题目依据、可行性说明和风险提示。
这一步看起来很普通，但它决定了后面所有设计。如果连输入和输出都没有定义清楚，智能体就很容易变成一个什么都能说、但没有明确结果的聊天机器人。
二、把一个大任务拆成几个小任务
一个真正能用的智能体，通常不是靠一次大模型调用完成全部工作，而是把大任务拆成多个小任务。
智能选题可以拆成下面九步：
- 了解用户想研究什么，确认研究范围。
- 把大方向拆成几个具体主题。
- 整理同义词、缩写和相关术语。
- 根据不同主题制定检索方案。
- 搜集文献，建立可以回看的证据池。
- 分析研究趋势、交叉方向和可能的空白。
- 根据前面的结果生成候选题目。
- 对候选题做去重、评分和质量检查。
- 把结果整理成报告，并交给用户确认。
这九步不一定要对应九个独立的页面，也不一定每一步都要使用一个不同的模型。它们更像是九个明确的工作阶段。拆开以后，开发人员才知道每一步应该输入什么、输出什么，出了问题应该从哪里检查。
三、第一步要做边界确认
用户说“我想研究人工智能在科研中的应用”，这个信息还不够。人工智能可以指模型、算法，也可以指具体应用；科研可以指文献检索、实验设计、知识发现，范围非常大。
所以智能体拿到任务以后，不能马上开始生成题目，而是先确认几个基本问题：研究对象是什么，准备解决什么问题，关注哪些年份，有没有数据或实验条件，最后想做偏理论还是偏应用的研究。
如果用户没有提供这些内容，智能体可以主动追问。也可以先采用默认范围继续执行，但要把这个默认条件记录下来。这样用户看到结果时，知道系统是在什么前提下分析的。
这一阶段的核心不是让模型多说话，而是避免后面一直在错误的方向上工作。
四、第二步是主题拆解和关键词整理
确定边界以后，再把研究方向拆成几个可以检索的问题。
比如用户输入“生成式人工智能如何参与科研知识发现”，可以继续拆成文献推荐、跨学科知识关联、语义检索、知识图谱和科研智能体等方向。拆解以后，每个方向都可以单独检索和比较，不会把所有内容混成一团。
同时还要整理关键词。一个概念可能有中文名、英文名、缩写和旧称。如果只使用用户输入的原话，很容易漏掉相关文献；但如果把所有相关词都塞进一个搜索条件里，又会带来很多无关结果。
这里可以让大模型帮助理解和归纳，但关键词最终要经过程序整理，最好把原始关键词、扩展关键词和排除关键词分别保存下来。这样后面发现检索结果不对时，才知道应该调整哪一部分。
五、让智能体会调用工具，而不是只会生成文字
智能体和普通问答最大的区别之一，就是它应该能够根据任务调用工具。
在智能选题里，工具可能包括文献搜索、文献详情获取、去重、年份统计、关键词统计和报告生成。模型负责判断当前需要做什么，程序负责真正执行这些动作。
比如模型判断“现在需要查询近五年的代表性文献”，它可以生成一个结构化的检索条件；检索程序拿着这个条件去查文献，再把结果返回给模型。模型继续分析结果，发现某个方向资料太少，就可以调整关键词后再次检索。
这里有一个很重要的原则：工具返回什么，模型就只能基于什么继续判断。不能因为没有查到结果，就让模型自己补几篇论文；也不能因为用户希望看到五个题目，就强行凑出五个没有依据的题目。
六、模型和普通程序各负责什么
开发智能体时，不要把所有事情都交给大模型。比较稳妥的做法，是把需要理解的工作交给模型，把结果确定的工作交给程序。
模型适合做这些事情：理解用户的问题，归纳文献主题，解释不同研究的区别，整理研究空白，用比较容易读懂的语言写报告。
程序适合做这些事情：调用检索接口，去重，统计年份，保存文献编号，计算分数，检查引用是否存在，记录每个阶段的运行状态。
例如“这几篇文献主要研究什么”可以让模型总结；“一共有多少篇文献、哪些文献重复、引用编号是否连续”就应该交给程序处理。
这样分工以后，模型负责发挥理解能力，程序负责保证数据不会随意变化。即使换一个模型，文献数量、引用编号和任务状态也不会跟着变来变去。
七、候选题目不是凭空生成的
前面的信息准备好以后，才进入候选题生成阶段。这个时候模型可以发挥语言组织能力，但题目必须来自前面的分析结果。
一个合格的候选题，至少应该能够回答三个问题：研究对象是什么，准备解决什么问题，和已有研究相比可能有什么区别。
比如系统发现某个方向的研究大多集中在通用数据集上，但真实场景数据验证不足，那么候选题就可以围绕真实场景验证来设计。这个题目的来源是前面发现的问题，而不是模型临时想到的一句话。
生成以后还要做去重。有些题目只是换了表达方式，实际研究内容完全一样；有些题目虽然方向相近，但研究方法不同，可以保留下来比较。
八、评分是帮助比较，不是替用户做决定
候选题生成以后，我会从新颖性、可行性、证据支持、资源匹配和风险几个角度进行比较。
这里的评分不代表第一名就是最好的题目。它只是帮助用户看清楚不同方案的优缺点。一个题目可能很新，但需要大量数据；另一个题目可能没有那么新，但用户已经有成熟的实验条件，实际反而更适合马上开始。
所以报告里除了分数，还要把评分理由写出来。用户应该能看到这个分数是怎么来的，而不是只看到一个看起来很准确的数字。
九、一定要保存过程，还要给失败留出口
智能体运行过程中，不能只保存最后一段报告。每个阶段的输入、输出和状态都应该保留下来，至少要知道当前执行到哪里、使用了哪些文献、哪一步出现了问题。
如果检索服务暂时不可用，系统可以重试或使用降级方案；如果用户的研究范围太模糊，就应该请求补充；如果文献证据不足，就把结果标记为需要人工确认，而不是继续生成一个很确定的结论。
这也是智能体和一次性脚本的区别。脚本通常只关心成功结果，智能体还要处理等待、重试、暂停、恢复和人工介入。
十、开发智能体时最容易犯的几个错误
第一，直接写一个很长的提示词，让模型自己完成全部步骤。这样做看起来简单，但很难检查，也很难定位问题。
第二，只看最终文字是否通顺，不检查引用和数据。报告写得好看，不代表内容有依据。
第三，为了让结果看起来完整，强行生成固定数量的答案。证据不够时，少给几个候选题，比凑出几个看似新颖但无法验证的题目更可靠。
第四，没有设计人工确认。科研选题涉及专业判断，智能体应该帮助人缩小范围、整理材料，而不是假装自己可以替人做最终决定。
最后：先把流程跑通，再慢慢增加智能
如果让我给刚开始开发智能体的开发人员一个建议，我会建议先不要追求“完全自主”。先找一个边界清楚的小任务，把输入、输出、工具、状态和异常情况设计明白。
以智能选题为例，第一版甚至可以只完成一条简单链路：接收研究方向，拆分关键词，搜索文献，整理结果，生成两个候选题，并把引用保存下来。等这条链路能够稳定运行以后，再增加评分、趋势分析、人工复核和报告导出。
智能体开发的重点，不是让模型说更多话，而是让它在正确的时间做正确的事情。模型负责理解和表达，程序负责执行和校验，用户负责确认关键判断。把这三件事分清楚，智能体才有机会从一次演示，真正变成一个别人愿意反复使用的工具。
1852
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
