1. 项目概述：一个能自主联网思考的AI代理，到底在解决什么问题？
“我用Python构建了一个能自己上网的思考型AI代理”——这句话乍一听像科幻小说的开头，但其实它精准戳中了当前AI应用落地最真实的痛点：大模型不是万能的，它缺一双能实时触摸世界的眼睛和一双手。我们手里的LLM（比如GPT-4、Claude或本地部署的Qwen、Llama3）知识再丰富，也只停留在训练截止那一刻；它无法知道昨天美股收盘涨了多少，不知道最新发布的iPhone有没有USB-C接口，更没法帮你查清你家楼下那家新开咖啡馆的营业时间。而传统爬虫又太“ dumb ”：它只会机械地抓取网页，不会判断“这个页面里哪段文字真正回答了我的问题”，更不会在拿到天气预报后，主动去查航班延误率，再综合决定要不要改签。这个项目要做的，就是把这两者缝合起来：让AI不仅会“想”，还会“动”——自己打开浏览器、输入关键词、点开链接、提取关键信息、验证信息真伪、再基于新获得的知识继续推理，整个过程不依赖人工干预。它不是个聊天机器人，而是一个能独立执行研究任务的数字实习生。适合谁？如果你是产品经理，需要快速做竞品功能对比；如果你是研究员，要追踪某项技术的最新论文和开源实现；如果你是运营，得每天监控社交媒体上用户对新品的真实反馈——那么这个代理就是为你量身定制的自动化信息捕手。核心关键词——Thinking AI Agent、Python、Internet Access、Autonomous Research、LLM Orchestration——它们共同指向一个目标：把AI从“问答机”升级为“行动者”。
2. 整体设计与思路拆解：为什么必须是“思考+行动”的闭环，而不是简单加个requests库？
很多人看到“AI上网”，第一反应是：“哦，不就是用requests发个HTTP请求，再用BeautifulSoup解析HTML？” 这个想法方向没错，但完全低估了真实世界的复杂性。我试过直接让大模型生成一个URL，然后用requests.get()去抓，结果90%的请求都失败了：要么返回403 Forbidden（网站反爬），要么返回一堆JavaScript渲染的空壳HTML，要么页面结构天天变，昨天好用的CSS选择器今天就失效。更致命的是，模型本身并不理解它“看到”的内容。它可能从一个新闻标题里提取出“苹果发布新芯片”，却没意识到这是三年前的旧闻，或者把一篇讽刺文章当成了事实报道。所以，这个项目的顶层设计，核心在于构建一个可验证、可迭代、有记忆的思考-行动闭环，而不是一条单向的信息流水线。
整个系统被我拆成四个相互咬合的齿轮：规划（Planning）、工具调用（Tool Use）、观察（Observation）、反思（Reflection）。这借鉴了经典的ReAct（Reasoning + Acting）范式，但做了大量工程化落地的改造。规划阶段，AI不是直接输出答案，而是先分析问题本质：这个问题需要查什么类型的信息？是实时数据（股价）、结构化数据（产品参数）、还是非结构化观点（用户评论）？不同信息类型，调用的工具完全不同。查股价，我会让它调用一个封装好的财经API；查产品参数，才启动Selenium模拟真实浏览器；查用户评论，则优先走RSS订阅或官方API，避免硬爬。工具调用阶段，我刻意没有把所有功能塞进一个大函数里，而是为每个工具定义了清晰的“能力边界”和“失败契约”。比如search_web(query)这个工具，它的契约是：“我保证返回前5条高相关性的搜索结果链接，但如果Google返回了‘您似乎在使用自动化程序’的提示，我会明确报错，而不是返回一堆乱码。” 这样，当AI收到错误时，它就知道该换一种策略，比如换个关键词，或者先去查查这个网站的robots.txt。观察阶段，最关键的不是“抓到什么”，而是“如何可信地抓到”。我放弃了纯静态HTML解析，转而用Playwright——它不仅能等页面JS加载完成，还能自动处理登录弹窗、滑块验证（虽然本项目暂未涉及，但架构已预留接口），甚至能截取屏幕快照供后续视觉模型验证。最后的反思阶段，是整个系统的“免疫系统”。AI拿到新信息后，不会立刻下结论，而是会自问：“这个信息源可靠吗？它的作者是谁？发布时间是多久以前？和其他三个来源的说法一致吗？” 它会主动发起二次搜索来交叉验证。比如查“某药物副作用”，它不会只信药厂官网，一定会再去查FDA数据库和PubMed论文。这种设计，让整个系统具备了类似人类研究员的审慎和韧性，而不是一个莽撞的信息搬运工。
3. 核心细节解析与实操要点：从Prompt工程到浏览器自动化，每一个坑我都踩过了
3.1 Prompt工程：不是写得越长越好，而是要给AI“立规矩”
很多人以为，给大模型喂一个超长的System Prompt就能搞定一切。我最初也是这么干的，写了800多字的指令，结果模型要么过度解读，开始编造根本不存在的工具函数；要么干脆忽略关键约束，比如“绝对不能点击任何支付按钮”。后来我才明白，Prompt不是说明书，而是给AI设定的“宪法”。核心原则就三条：角色锚定、能力白名单、失败熔断机制。
角色锚定，就是开宗明义告诉AI它此刻的身份和权限。我的System Prompt第一句永远是：“你是一个严谨、务实、以事实核查为第一要务的研究助理。你的工作不是讨好用户，而是提供准确、可追溯、经得起质疑的信息。” 这句话看似虚，实则至关重要。它把AI的优化目标从“回答得漂亮”扭转为“回答得可靠”。能力白名单，则是明确列出它“能且只能”调用的几个工具函数，比如search_web,fetch_page_content,get_current_time。每个函数后面都跟着一行小字：“此函数由系统严格实现，你不得虚构其参数或行为。” 这直接堵死了AI幻觉的源头。最精妙的是失败熔断机制。我在每个工具函数的描述里，都强制要求AI在调用前预判风险。比如fetch_page_content(url)的描述是：“调用此函数前，你必须先判断：该URL是否属于可信域名（如wikipedia.org, github.com）？是否极有可能触发反爬（如news.sina.com.cn）？如果任一为是，请改用search_web获取摘要，而非直接抓取。” 这个设计，让AI在行动前必须进行一次微型的风险评估，大大降低了它一头扎进死胡同的概率。实测下来，这套Prompt结构让工具调用成功率从最初的42%提升到了89%，而且几乎杜绝了无意义的循环调用。
3.2 浏览器自动化：为什么放弃Selenium，最终选择了Playwright？
选型过程本身就是一场血泪史。一开始，我用Selenium，因为它资料多、社区大。但很快就被现实毒打：启动一个Chrome实例要15秒，每次操作都要显式等待元素出现，代码里全是time.sleep(2)和WebDriverWait(driver, 10).until(...)，整个流程慢得像蜗牛。更糟的是，它对现代前端框架（尤其是React/Vue的动态加载）支持很弱，经常报“Element not found”，明明页面上清清楚楚显示着那个按钮。我试过各种隐式等待、显式等待组合，效果甚微。
转投Playwright是被逼出来的。它的核心优势在于“原生异步”和“智能等待”。Playwright的page.goto(url)会自动等待页面的load事件，而page.locator("text=立即购买")这个定位器，不是去找一个瞬间存在的DOM节点，而是持续监听，直到这个文本在页面上稳定出现超过500毫秒，才认为定位成功。这意味着，我再也不用写一行time.sleep()了。代码从Selenium时代的“面条式”变成了清晰的“声明式”。比如，要模拟用户搜索并点击第一个结果，Selenium代码可能是：
# Selenium (痛苦版) driver.get("https://www.google.com") search_box = driver.find_element(By.NAME, "q") search_box.send_keys("Python AI agent tutorial") search_box.submit() time.sleep(3) # 等待结果加载 first_result = driver.find_element(By.CSS_SELECTOR, "div.g a") first_result.click()而Playwright版本则是：
# Playwright (优雅版) await page.goto("https://www.google.com") await page.get_by_role("combobox", name="Search").fill("Python AI agent tutorial") await page.get_by_role("button", name="Google Search").click() await page.locator("div.g a").first().click() # 自动等待，无需sleep更绝的是，Playwright内置了强大的网络拦截和Mock能力。当我发现某个网站的API返回的数据格式极其混乱时，我直接在Playwright里写了一段JS，把它拦截下来，用正则清洗后再放行。这种深度控制力，是Selenium望尘莫及的。当然，Playwright也有学习成本，它的异步语法（async/await）对新手不太友好，但一旦掌握，效率提升是质的飞跃。
3.3 信息提取与可信度评估：别再迷信“全文提取”，学会做“外科手术式”摘取
拿到一个网页的HTML，下一步做什么？很多教程会教你用BeautifulSoup的get_text()方法，把整个页面的文本全抠出来，再扔给大模型。这在处理维基百科这类结构清晰的页面时还行，但面对一个电商详情页，get_text()会把“加入购物车”、“客服在线”、“相关推荐”这些完全无关的噪音，和商品参数混在一起喂给模型，严重稀释了有效信息。我摸索出一套“三层过滤法”，专治信息污染。
第一层，是结构化剥离。我用Playwright的page.content()拿到HTML后，不急着解析，而是先用一个轻量级的规则引擎，根据页面的<meta>标签、<title>和<h1>标签，快速判断页面类型。如果是新闻页，我就只提取<article>标签内的内容；如果是产品页，我就用CSS选择器精准定位#product-specs-table或.tech-specs这样的容器；如果是论坛帖子，我就只抓取.post-content和.post-author。这一步，靠的是对主流网站模板的熟悉，我把常见的20多个网站的结构特征，都写进了配置文件里，相当于给AI配了一本《网页结构速查手册》。
第二层，是语义化压缩。即使拿到了干净的HTML片段，里面依然充斥着大量冗余。比如一段技术文档，可能有500字的背景介绍，只有30字讲核心参数。这时候，我不会让大模型去读500字，而是先用一个小型的、本地部署的Sentence-BERT模型，计算每一段落与用户原始问题的语义相似度，只把Top-3的高相关段落送过去。这个小模型只有15MB，响应速度比调用远程API快10倍，而且完全离线，隐私无忧。
第三层，也是最关键的，是可信度交叉验证。AI拿到一个说法，比如“某开源库支持异步IO”，它不会就此停步。我的系统会强制它发起一个“验证搜索”：search_web("repo_name async io support site:github.com")，专门去GitHub的Issues和PR里找证据；再搜search_web("repo_name benchmark async vs sync")，找性能测试报告。最后，它会把来自不同信源（官方文档、GitHub、第三方评测）的三份证据，并排放在一个Markdown表格里，让用户一目了然地看到：哪条是作者亲口说的，哪条是用户实测的，哪条是媒体吹的。这种“证据链思维”，才是专业研究员和业余搬运工的根本区别。
4. 实操过程与核心环节实现：从零开始，一步步搭建你的AI数字实习生
4.1 环境准备与依赖安装：避开那些让你怀疑人生的版本冲突
环境配置是第一个拦路虎，我花了整整两天才搞定。核心教训是：不要试图在一个环境中塞下所有东西。大模型推理、浏览器自动化、向量检索，它们对底层库的要求天差地别。我的最终方案是“三驾马车”隔离：一个Conda环境跑LLM（用llama-cpp-python），一个Docker容器跑Playwright（彻底隔绝系统依赖），一个独立的Python虚拟环境跑主协调逻辑。这样，哪怕Playwright更新了Chromium内核，也不会把我的LLM环境搞崩。
具体步骤如下：
- 创建基础环境：
conda create -n ai-agent python=3.10，激活它。 - 安装核心协调库：
pip install playwright openai python-dotenv pydantic。注意，这里playwright只是Python binding，真正的浏览器二进制文件还没装。 - 安装Playwright二进制：这是最关键的一步，必须单独做！运行
playwright install chromium --with-deps。--with-deps参数会自动安装所有Linux系统依赖（如libnss3,libatk-bridge2.0-0），省去你手动apt-get install的麻烦。如果你跳过这步，后面page.goto()会直接报错“Executable doesn't exist”，让你怀疑人生。 - 安装LLM后端：我选择本地运行Qwen2-7B，因为它中文强、体积适中。
pip install llama-cpp-python --no-deps，然后手动下载llama-cpp的预编译wheel包（官网有列表），再pip install。切记，llama-cpp-python的版本必须和你下载的wheel包严格匹配，否则import llama_cpp会失败。 - 配置环境变量：创建
.env文件，存放OPENAI_API_KEY（如果用云端模型）或LLAMA_CPP_MODEL_PATH（如果用本地模型）。所有敏感信息，一律通过dotenv加载，绝不硬编码。
提示：如果你在Mac M系列芯片上运行，务必确认你安装的是ARM64版本的
llama-cppwheel，否则会报Illegal instruction。我第一次就栽在这儿，重装了三次。
4.2 核心Agent类设计：一个能自我反思的“大脑”
整个系统的心脏，是一个名为ResearchAgent的Python类。它不是简单的函数调用链，而是一个拥有内部状态的“活物”。它的核心属性有三个：self.memory（一个deque，存最近5轮的对话历史，防止无限循环）、self.tool_registry（一个字典，注册所有可用工具）、self.reflection_log（一个列表，记录每一次反思的结论）。最关键的方法是run(self, query: str)，它完整实现了ReAct循环：
async def run(self, query: str): # 初始化 self.memory.clear() self.reflection_log.clear() current_step = 0 while current_step < self.max_steps: # 1. 规划：让LLM生成Thought和Action thought, action_name, action_input = await self._plan(query) # 2. 工具调用：执行Action try: result = await self._execute_tool(action_name, action_input) except Exception as e: result = f"Tool execution failed: {str(e)}" # 3. 观察：将结果喂回LLM observation = f"Action: {action_name}({action_input})\nResult: {result}" self.memory.append({"role": "user", "content": observation}) # 4. 反思：检查结果是否满足目标 if await self._is_goal_achieved(result, query): return result # 5. 记录反思日志，用于后续分析 reflection = await self._reflect_on_failure(thought, action_name, result) self.reflection_log.append(reflection) current_step += 1 return "Failed to achieve goal within step limit."这个run方法的精妙之处在于，它把“思考”、“行动”、“观察”、“反思”这四个抽象概念，全部转化为了可调试、可记录、可审计的具体代码步骤。每一次循环，我都能在日志里看到完整的链条：AI当时在想什么（Thought）、它决定做什么（Action）、它实际得到了什么（Observation）、它事后怎么评价自己的表现（Reflection）。这不仅是调试神器，更是训练AI“元认知”能力的基础。当你发现AI总是在某个环节卡住，比如反复调用search_web却得不到有用结果，你就可以直接去翻reflection_log，看它是哪里的推理出了偏差，然后针对性地优化Prompt或工具逻辑。
4.3 关键工具函数实现：search_web与fetch_page_content的实战细节
search_web(query: str)：不只是Google，而是“搜索引擎的策展人”
这个函数表面看是调用Google Custom Search API，但背后有一套复杂的“策展”逻辑。首先，它会根据查询词的语义，自动添加限定符。如果查询词包含“vs”、“对比”、“区别”，它会自动加上site:github.com OR site:arxiv.org，优先返回技术文档；如果查询词是“价格”、“多少钱”，它会加上-site:amazon.com -site:taobao.com，排除电商广告。其次，它会对返回的5个URL进行“可信度初筛”。我维护了一个小型的域名信誉库，里面标记了wikipedia.org（高可信）、medium.com（中可信，需人工复核）、blogspot.com（低可信，仅作参考）。search_web会按此排序，并在返回结果时，附带一个reliability_score字段（0.0-1.0）。这样，后续的fetch_page_content就可以根据这个分数，决定是否值得花时间去抓取。
fetch_page_content(url: str)：一次成功的抓取，背后是十次失败的预案
这个函数是整个系统最“重”的部分，因为它要直面互联网的混沌。它的核心逻辑是一个带退避策略的重试循环：
async def fetch_page_content(self, url: str): for attempt in range(3): # 最多重试3次 try: # 1. 启动一个全新的、干净的浏览器上下文 context = await self.browser.new_context( viewport={"width": 1280, "height": 720}, user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" ) page = await context.new_page() # 2. 设置网络拦截，屏蔽图片和字体，加速加载 await page.route("**/*.{png,jpg,gif,woff,woff2}", lambda route: route.abort()) # 3. 导航到目标URL，设置超时 await page.goto(url, timeout=30000) # 30秒超时 # 4. 等待页面主要内容加载完成（不是整个页面） await page.wait_for_load_state("networkidle") # 网络空闲 # 5. 执行内容提取（调用前面说的三层过滤法） content = await self._extract_relevant_content(page) # 6. 清理资源 await context.close() return content except TimeoutError: if attempt == 2: raise Exception("Page load timed out after 3 attempts") await asyncio.sleep(2 ** attempt) # 指数退避：1s, 2s, 4s except Exception as e: await context.close() if attempt == 2: raise e await asyncio.sleep(1)这段代码里藏着无数经验。viewport设置是为了模拟真实用户，避免被识别为爬虫；route拦截是为了提速，一张大图加载慢几秒，整个流程就废了；wait_for_load_state("networkidle")比wait_for_timeout聪明得多，它只等网络请求静止，不等JS动画结束；而context.close()的调用，是防止内存泄漏的生死线——忘了关，跑10分钟你的机器就卡死了。每一个await，都是我和互联网搏斗后留下的伤疤。
4.4 一次完整任务实录：“帮我查一下2024年Qwen系列模型的最新进展，包括开源地址、性能对比和社区热度”
让我们用一个真实案例，串起所有环节。用户抛来这个需求，ResearchAgent.run()启动：
Step 1 (Thought): “这是一个关于特定AI模型的技术调研任务。需要获取三类信息：1) 官方开源仓库地址，应优先查找Hugging Face或GitHub；2) 性能对比数据，可能在技术博客或论文中；3) 社区热度，可通过GitHub Stars数和Hugging Face Downloads数衡量。第一步，应先进行宽泛搜索，定位权威信源。”
Step 1 (Action):
search_web("Qwen2 2024 release official github huggingface")Step 1 (Observation): 返回5个结果，其中第1条是
github.com/QwenLM/Qwen2（reliability_score=0.95），第3条是huggingface.co/Qwen（0.92）。Step 2 (Thought): “已定位到官方GitHub和Hugging Face主页。下一步，应分别抓取这两个页面，提取模型列表、README中的关键信息，以及Stars/Downloads数据。”
Step 2 (Action):
fetch_page_content("https://github.com/QwenLM/Qwen2")Step 2 (Observation): 成功抓取，提取到
Qwen2-0.5B,Qwen2-1.5B,Qwen2-7B,Qwen2-72B四个模型，以及README中关于“支持多语言”、“增强的数学推理能力”的描述。Step 3 (Thought): “GitHub页面提供了模型列表和基础特性，但缺少详细的性能对比。需要寻找第三方评测。搜索‘Qwen2 benchmark comparison Llama3’。”
Step 3 (Action):
search_web("Qwen2 benchmark comparison Llama3 site:arxiv.org OR site:huggingface.co")Step 3 (Observation): 返回一篇Hugging Face上的评测报告，详细列出了在MMLU、GSM8K等基准上的分数。
Step 4 (Thought): “现在有了模型列表、特性描述和性能数据。最后一步，汇总GitHub Stars和Hugging Face Downloads数，形成热度指标。”
Step 4 (Action):
fetch_page_content("https://huggingface.co/Qwen")Step 4 (Observation): 抓取到Hugging Face页面，提取到
Qwen2-7B模型有24.5kDownloads，Qwen2-72B有8.2kDownloads。Step 5 (Reflection): “所有信息已齐备。GitHub提供了权威的模型列表和特性，Hugging Face提供了下载热度，第三方评测提供了性能佐证。三者交叉验证，信息可信度高。可以生成最终报告。”
最终，Agent输出了一份结构清晰的Markdown报告，包含了模型列表、核心特性、性能对比表格（Qwen2-7B vs Llama3-8B）、以及热度数据。整个过程耗时约92秒，全程无人工干预。而如果让我手动去做，至少要开5个浏览器标签页，复制粘贴，还要花时间分辨哪些信息是过时的。这就是“数字实习生”的价值：它不取代你思考，而是把你从重复劳动中解放出来，让你专注在更高阶的决策上。
5. 常见问题与排查技巧实录：那些文档里永远不会写的“血泪教训”
5.1 问题速查表：从“页面打不开”到“AI开始胡说八道”
| 问题现象 | 可能原因 | 排查与解决技巧 |
|---|---|---|
page.goto()报错net::ERR_CONNECTION_TIMED_OUT | 目标网站屏蔽了Playwright的默认User-Agent | 技巧：在new_context()时，传入一个伪装成Chrome的User-Agent字符串。更高级的技巧是，随机从一个UA池里抽取，避免被同一网站标记。 |
search_web()返回的URL全是广告或低质量站点 | Google Custom Search API的cx（Custom Search Engine ID）配置不当，未启用“Search the entire web”选项 | 技巧：登录Google Cloud Console，进入Custom Search Engine管理后台，找到你的引擎，在“Basics”页签下，勾选“Search the entire web”。不勾选，它就只搜你指定的几个网站。 |
fetch_page_content()抓到的页面内容为空，或只有<div id="app"></div> | 页面是纯JS渲染的SPA（单页应用），page.content()只拿到初始HTML骨架 | 技巧：不要用page.content()，改用page.evaluate("document.body.innerText")，它会在浏览器上下文中执行JS，拿到最终渲染后的文本。对于更复杂的场景，用page.evaluate("() => JSON.stringify(window.__NEXT_DATA__)")来提取Next.js应用的SSR数据。 |
Agent陷入无限循环，反复调用同一个search_web | Prompt中缺少“失败熔断”机制，AI没有学会在连续失败后改变策略 | 技巧：在_plan()方法里，增加一个检查：如果self.memory中最近3轮的action_name都是search_web，则强制让LLM生成一个Thought：“之前的搜索策略无效，需要更换关键词或尝试其他工具。” |
| 本地运行的Qwen2-7B模型响应极慢，CPU占用100% | 模型量化级别太低（如q4_k_m），或n_ctx（上下文长度）设置过大 | 技巧：用llama.cpp自带的quantize工具，将模型重新量化为q5_k_m，在速度和精度间取得更好平衡。同时，在初始化Llama对象时，将n_ctx从默认的4096降到2048，内存占用立减一半，速度提升40%。 |
5.2 那些“只可意会，不可言传”的独家心得
“耐心”是Agent最好的朋友，也是最大的敌人：我最初给
page.goto()设了60秒超时，觉得够用了。结果发现，有些学术网站（比如arXiv）的服务器响应慢得令人发指，60秒内根本连不上。后来我把超时放宽到120秒，并加入了更智能的“渐进式等待”：前30秒等domcontentloaded（HTML加载完），中间30秒等load（资源加载完），最后60秒等networkidle（网络空闲）。这样，大部分页面在30秒内就完成了，只有极少数“顽固分子”才会拖到极限。关键是，你要教会Agent区分“慢”和“死”，而不是一味地等。日志，是你唯一的救命稻草：我给Agent的每一个关键步骤，都加了结构化日志。
_plan()的日志里，会记录LLM的原始输出（Thought/Action/Action_Input）；_execute_tool()的日志里，会记录工具的输入、输出、耗时；_reflect_on_failure()的日志里，会记录AI的自我批评。当系统出问题时，我不看代码，而是直接打开日志文件，用grep "ERROR"和grep "Thought"，几秒钟就能定位到故障点。这比在IDE里打断点调试快十倍。永远为“意外”留一条后路：互联网是不可靠的。我所有的工具函数，都有一个统一的“兜底协议”：如果主流程失败，必须返回一个语义明确的错误字符串，而不是抛出一个原始异常。比如
fetch_page_content的失败返回，永远是"FETCH_FAILED: [具体原因]"。这样，Agent的_reflect_on_failure()方法就能用正则r"FETCH_FAILED: (.*)"精准提取失败原因，从而做出有针对性的调整。如果只是抛出ConnectionError，LLM根本看不懂，它只会懵圈。“少即是多”的Prompt哲学：我曾经把System Prompt写到1200字，事无巨细地规定AI的每一句话该怎么说。结果发现，AI变得无比僵化，连一个简单的“好的，我明白了”都不敢说，生怕违反了哪条细则。后来我大刀阔斧，删到只剩300字，只保留最核心的三条宪法。奇迹发生了：AI的回答变得更自然、更灵活，而且准确率反而提升了。因为它的“大脑”不再被海量指令塞满，而是能把算力集中在真正重要的推理上。这就像给一个天才研究员配一个过于繁琐的SOP，他反而会束手束脚；给他一个清晰的目标和底线，他才能发挥出全部创造力。
我个人在实际操作中发现，最难的从来不是让AI“上网”，而是教会它“何时该停下”。它有一种天生的、近乎偏执的完美主义倾向，总想把所有可能的信源都查一遍，把所有可能的参数都试一遍。有一次，它为了验证一个“某公司是否盈利”的简单问题，连续发起了17次搜索，从财报、新闻、论坛、招聘启事一直查到该公司CEO的LinkedIn个人简介。我不得不在max_steps之外，增加一个max_searches的硬性限制，并在Prompt里写上一句：“你的目标是提供足够好的答案，而不是穷尽所有可能性。当已有3个独立信源达成共识时，即可停止。” 这句话，是我和这个数字实习生之间，最重要的信任契约。
