三个Agent的分工规划、总结、报告各管一段。一开始觉得这样是不是太死板了三个Agent轮流工作效率会不会不如一个Agent从头干到尾。后来注意到一个细节每个Agent的prompt都是单独写的专门针对自己那段任务。规划那个prompt强调要返回JSON总结那个强调要加引用标记报告那个强调合并重复信息。如果用一个Agent干全部prompt会变得又臭又长而且改一处会牵动另一处。顺序协作虽然简单但确实好调试。哪一步输出不对就单独看那一步的prompt和中间结果不用怀疑别的地方。Service层代码里有个设计我一开始没看懂为什么要有 PlanningService、SummarizationService 这些类Agent 直接跑不就行了看完才明白Service 是把Python 该干的活从 Agent 手里拿走。比如PlanningService 里要做的事填prompt模板、从返回文本里用正则抠出JSON、验证字段全不全SummarizationService 里要做的事把搜索结果格式化成带编号的文本、从总结里把来源URL提取出来。这些都是确定性的活不需要模型推理。放在 Python 代码里写死比写在 prompt 里让模型自己搞定要可靠得多。Agent 的 prompt 因此可以保持得很短只说你是研究规划专家这种角色定位不用夹杂一堆格式要求。几个注意点第一不能假设大模型只会输出JSON。哪怕prompt里明确写了只返回JSON不要其他文本它经常会先来一句好的我来帮你规划...。所以解析的时候得先用正则把 [...] 那段抠出来再做 json.loads。第二搜索结果要去重。不同关键词经常命中同一个网页不去重的话列表里一堆重复的链接既浪费token又干扰模型判断。第三搜索失败不能让整个流程崩。SearchService 里搜不到东西就返回空列表让上层继续往下走别抛异常。因为研究主题冷门的时候搜不到是常事。关于ToolAwareSimpleAgent刚开始看这个类名有点懵为什么要单独搞一个 Agent 出来。想通了其实就一句话工具调用的时候要让外面知道。深度研究整个过程可能跑几分钟用户在前端如果只能看着一个转圈体验很差。有了这个回调机制每次调搜索工具都能实时推给前端显示正在搜索xxx。实现上就是继承原 Agent把执行工具的那个方法重写一下前后加一层通知。这个套路挺通用的以后如果想在Agent运行过程中做任何监控都可以这么干。避开perplexity搜索由于本节用到perplexity api但是尝试了很久网页完全加载不了想到了前面学习内容中也有注册了的搜索API就尝试再环境中加上了SerpApi搜索但是后面运行的时候看到提示未安装 google-search-results无法使用 SerpApi 搜索然后网页端尝试运行的时候看到也无法正常执行工作流。然后就开始查出处从backend\src\services\search.py到库文件的tools\builtin\search_tool.py,查到0.2.8版本里面写的“from serpapi import GoogleSearch”改为“from serpapi.google_search import GoogleSearch”后就正常运行了。关于本节的想法现在这套流程是完全线性的规划完就执行执行完就写报告。但实际研究中看第一轮结果的时候经常会冒出新的问题需要再补一轮搜索。文中提到了一种反思机制的可能但没展开。我的想法是可以加一个评审Agent在报告写完之前检查一遍——有没有哪个TODO总结得太浅、有没有互相矛盾的地方、有没有漏掉明显该查的角度。如果发现问题就回退到执行阶段补一轮。不过这样会让流程复杂不少作为学习案例就先跑通最简的线性流程后续根据学习积累自己再动手实践实践。参考链接1、【Hello-Agents进阶篇开源地址】https://github.com/datawhalechina/hello-agents2、聪明办法学Pythonhttps://datawhalechina.github.io/learn-python-the-smart-way-v2/3、DeepAgent实战课程https://datawhalechina.github.io/deepagents-in-action/