1. 项目缘起当市场研究遇上本地优先与多Agent最近在做一个市场研究项目需要频繁地爬取、整理和分析不同来源的数据。我的工作流大概是这样的打开浏览器搜索关键词把网页内容复制到Notion或Excel里然后手动整理成表格再导入到数据分析工具里。这个过程不仅重复、枯燥而且效率极低。更头疼的是当需要追踪某个竞品或行业动态时我得反复在不同网站之间切换数据格式不统一信息也容易遗漏。我相信很多做市场、产品、投资分析的朋友都遇到过类似的困境。我们需要的不是一个又一个割裂的工具而是一个能“一站式”完成信息搜集、初步处理和结构化整理的“工作台”。市面上当然有类似的产品但它们要么是云端SaaS数据安全性和隐私性让我有所顾虑要么功能过于庞大笨重学习成本高要么就是定制化程度太低无法适配我个性化的研究流程。于是我萌生了自己动手做一个工具的想法。我的核心诉求很明确第一数据必须本地优先所有原始资料和处理结果都保存在我自己的电脑上让我有绝对的控制权第二要能自动化把那些重复的、机械的搜集和整理工作交给“智能体”去完成第三要轻量、易用最好是个桌面应用打开即用不依赖复杂的服务器环境。顺着这个思路“多Agent”Multi-Agent的架构自然浮现在脑海中。为什么不把不同的任务拆解交给多个各司其职的“智能体”去协作完成呢比如一个Agent专门负责从指定网站抓取内容另一个Agent负责解析网页结构并提取关键信息公司名、产品功能、发布时间等第三个Agent则负责将提取的信息按照我预设的模板整理成结构化的报告。它们像一条流水线上的工人共同完成“市场研究”这件复杂的事情。这就是Evidence Loom诞生的背景。Loom意为“织布机”我希望这个工具能像一台精密的织机将互联网上零散、杂乱的“信息丝线”通过多个智能体的协作编织成结构清晰、可直接用于决策的“证据布料”。它完全开源采用本地优先架构是一个专为深度信息工作者设计的桌面端多Agent市场研究工具。2. Evidence Loom的核心架构本地、模块化与智能体流水线Evidence Loom的整体设计哲学是“高内聚、低耦合”。整个应用采用典型的前后端分离架构但所有组件都运行在用户本地。2.1 技术栈选型与本地化考量在技术选型上我首要考虑的是跨平台能力和本地运行的便捷性。前端GUI我选择了Electron。原因很简单它允许我使用熟悉的Web技术HTML, CSS, JavaScript来构建桌面应用并且能轻松打包成Windows、macOS和Linux的本地可执行文件。用户下载后双击即可运行无需安装Python环境或配置服务器极大地降低了使用门槛。前端框架我用了Vue 3其响应式系统和组件化开发模式非常适合构建这种交互复杂的桌面应用。后端核心逻辑虽然Electron本身能跑Node.js但考虑到后续复杂的AI任务处理和数据操作我决定将核心业务逻辑剥离用一个独立的Python服务来承载。Python在数据处理Pandas, NumPy、网络爬虫BeautifulSoup, Scrapy以及AI模型调用LangChain, 各类LLM SDK方面有巨大的生态优势。这个Python服务会以后台进程的形式随Electron主程序启动。通信前端ElectronNode.js与后端Python服务之间通过本地HTTP API进行通信。Electron作为“外壳”负责界面渲染和用户交互当用户发起一个研究任务时前端会将任务配置通过HTTP请求发送给后端的Python服务Python服务处理完毕后再将结果或进度推回前端展示。这种设计使得前后端可以独立开发和迭代。数据存储贯彻“本地优先”所有数据都存在用户电脑上。我选用了SQLite作为主数据库。它无需安装数据库服务一个文件就是整个数据库非常轻量且通过Python的sqlite3模块或Node.js的better-sqlite3都能高效操作。原始网页的HTML快照、提取的结构化数据、任务日志等都存在SQLite文件中。对于非结构化的文档或缓存则直接使用本地文件系统。注意这里有一个关键细节。Python服务可能需要安装一些第三方包如langchain, playwright等。在打包Electron应用时我使用了pyinstaller将Python代码及其依赖打包成一个独立的可执行文件。最终用户拿到的安装包内会包含这个Python可执行文件和一个精简的Python运行时从而实现了真正的“开箱即用”用户完全无需关心Python环境问题。2.2 多Agent系统的设计与协作机制“多Agent”是Evidence Loom的大脑。这里的Agent并非指必须依赖GPT-4等大语言模型的复杂AI体而是一个个具有特定功能、能自主或在简单规则下执行任务的程序模块。我的设计遵循了“单一职责”原则。一个典型的市场研究任务会被拆解成如下Agent流水线采集Agent (Crawler Agent)它的职责是根据用户输入的关键词或种子URL去互联网上搜集相关信息。它可能整合了多种爬虫策略对于公开的新闻网站、博客使用playwright或selenium进行动态页面渲染和抓取。对于API友好的平台如部分社交媒体、产品发布平台则直接调用其公开API。这个Agent需要处理反爬机制、请求频率控制、错误重试等脏活累活并将抓取到的原始HTML或JSON数据存储到本地数据库并标记来源和时间戳。解析与提取Agent (Parser Extractor Agent)这是将非结构化数据转为结构化数据的关键一环。它接收采集Agent抓取的原始内容。规则提取对于结构稳定的网站如产品官网的规格表可以配置XPath或CSS选择器进行精准提取。AI增强提取对于结构多变或内容复杂的页面如一篇行业分析文章则调用本地的轻量级NLP模型或配置好的大语言模型API如OpenAI GPT, Claude等通过提示词工程Prompt Engineering让AI识别并提取出我们关心的实体和关系例如“从以下文章中提取提到的公司名称、其发布的新产品、产品的主要功能特点以及发布日期。”提取出的结构化数据键值对或表格会被存入SQLite的特定表中。整理与报告Agent (Synthesis Reporting Agent)它负责将提取Agent产出的零散数据按照用户预设的模板进行汇总、去重、关联和格式化。例如用户可能有一个“竞品功能对比表”的模板。这个Agent会去数据库里找出所有关于A公司、B公司、C公司的产品功能提取结果自动填充到表格的对应位置。它还可以进行简单的数据分析比如统计某个关键词在不同来源中出现的频率生成趋势图表。最终它可以输出为Markdown、HTML、Excel或PDF格式的报告保存到用户指定的本地文件夹。调度与协调Agent (Orchestrator Agent)这是一个隐形的“指挥官”它不直接处理数据而是负责任务流的调度。它接收用户在前端创建的任务例如“监控A、B、C三家公司在未来一周内关于‘人工智能芯片’的所有动态”然后将其分解为采集、解析、整理等子任务按顺序或并行地触发相应的Agent去执行并监控整个流程的状态处理失败和重试。所有这些Agent都以Python模块或类的形式存在它们之间通过共享数据库SQLite和消息队列我使用了一个轻量级的本地消息队列如huey或直接使用内存队列进行松耦合的通信。这种设计的好处是显而易见的你可以非常方便地替换或升级某个Agent。比如觉得某个网站的解析规则失效了只需要修改Parser Agent里的对应代码而不影响其他部分。3. 从零到一手把手搭建你的第一个研究任务光讲架构可能有些抽象我们直接来看如何在Evidence Loom里实际创建一个研究任务。假设我想追踪几个开源机器学习框架例如PyTorch, TensorFlow, JAX近期的官方动态和社区讨论。3.1 环境准备与首次启动首先你需要获取Evidence Loom。因为是开源项目你可以直接从GitHub仓库克隆代码。git clone https://github.com/your-username/evidence-loom.git cd evidence-loom项目根目录通常会有清晰的README。对于开发者你可能需要分别启动前端和后端# 终端1启动后端Python服务 cd backend pip install -r requirements.txt # 安装Python依赖 python main.py # 终端2启动前端Electron应用 cd frontend npm install npm run electron:dev对于普通用户我会提供打包好的安装程序.dmg, .exe, .AppImage直接下载安装即可。首次启动后界面会相对简洁主要区域是任务列表、数据看板和设置。3.2 配置数据源与采集Agent创建一个新任务我们命名为“开源ML框架动态监控”。第一步是告诉工具去哪里找信息。在任务配置界面我们需要添加“数据源”。数据源类型选择“网站列表”。输入URL这里填入我们关心的官方渠道和社区。PyTorch博客:https://pytorch.org/blog/TensorFlow博客:https://blog.tensorflow.org/JAX官方更新:https://github.com/google/jax/releasesReddit的r/MachineLearning板块:https://www.reddit.com/r/MachineLearning/Hacker News:https://news.ycombinator.com/采集频率设置为“每日一次”。Evidence Loom的后台服务会以守护进程运行按计划自动触发采集。采集深度对于博客和发布页我们只采集第一层列表页的最新文章链接即可。对于Reddit和HN可以设置采集前3页的热门帖子。这里涉及到采集Agent的配置。对于不同的网站可能需要不同的爬虫策略。Evidence Loom内置了一个“智能适配”模式它会先尝试用通用的解析器如果失败你可以为特定网站配置自定义的提取规则。实操心得在配置Reddit、HN这类动态加载、反爬措施较多的网站时直接使用简单的HTTP请求如requests库往往拿不到完整内容。我强烈推荐在采集Agent中集成playwright。它可以模拟真实浏览器行为完美渲染JavaScript生成的内容。虽然比requests重一些但对于成功率要求高的场景这点开销是值得的。在Evidence Loom的配置文件中你可以为特定域名指定使用playwright驱动。3.3 设计信息提取模板采集到原始网页只是第一步我们需要从中提取出有价值的结构化信息。这就是解析与提取Agent发挥作用的时候。在任务配置的“解析器”部分我们需要为不同类型的数据源设计提取模板。这本质上是告诉AI或规则引擎“请从这种类型的页面里找出如下信息。”以“PyTorch博客文章”为例我们创建一个提取模板模板名称PyTorch Blog Post匹配规则URL包含pytorch.org/blog/且路径符合/blog/xxxx/格式。待提取字段title: 文章标题publish_date: 发布日期author: 作者content_summary: 文章内容摘要前500字符tags: 文章标签如“release”, “tutorial”framework: 固定为“PyTorch”这是一个常量字段提取方式选择“AI提取”。我们需要编写一段提示词Prompt “你是一个信息提取助手。请从下面的PyTorch官方博客文章中提取出文章标题、发布日期、作者、文章正文的前500个字符作为摘要以及文章关联的标签。请以JSON格式输出键名为title, publish_date, author, content_summary, tags。”对于TensorFlow博客和JAX的GitHub Release页面我们创建类似的模板只是匹配规则和“framework”字段的值不同。对于Reddit和Hacker News这类聚合站点模板会更通用一些提取字段可能包括post_title,post_url,source(e.g., “Reddit/r/MachineLearning”),score(点赞数),comment_count,discussion_summary(调用AI对高赞评论进行总结)等。3.4 设置自动化报告与输出最后我们配置整理与报告Agent让它定期生成报告。在“输出”配置中我们可以设置报告模板选择内置的“每日动态摘要”模板或自定义一个Markdown模板。触发条件设置为“每天上午9点汇总过去24小时内采集到的所有新条目”。输出格式选择“Markdown文件”和“电子邮件摘要”如果你配置了SMTP发送邮件。内容组织在模板中我们可以这样设计# 开源ML框架每日动态 {{date}} ## 官方发布 {% for item in items if item.source_type official_blog %} ### {{ item.framework }}: {{ item.title }} * **时间**: {{ item.publish_date }} * **摘要**: {{ item.content_summary }} * **链接**: {{ item.url }} {% endfor %} ## 社区热议 {% for item in items if item.source_type in [reddit, hackernews] %} ### {{ item.post_title }} * **来源**: {{ item.source }}, 热度: {{ item.score }} * **讨论摘要**: {{ item.discussion_summary }} * **链接**: {{ item.post_url }} {% endfor %}这是一个简单的Jinja2模板示例Evidence Loom的报告引擎会用真实数据填充它。输出路径指定一个本地文件夹如~/Documents/ML_Framework_Monitor/。配置完成后保存任务。Evidence Loom的调度Agent就会开始工作。它会在每天指定的时间或立即运行一次启动这个任务流水线采集Agent去抓取网页 - 解析Agent根据模板提取信息 - 整理Agent将新数据汇总并生成报告保存到你的本地文件夹。你每天早晨打开电脑就能在指定文件夹里看到一份结构清晰的Markdown报告汇总了过去一天所有你关心的开源ML框架动态无需再手动打开十几个网页逐一查看。4. 深入核心Agent协作的通信、状态管理与错误处理要让多个Agent稳定、可靠地协作背后的通信机制、状态管理和错误处理至关重要。这是Evidence Loom能否投入实际使用的关键。4.1 基于消息队列的松耦合通信我放弃了让Agent之间直接调用函数或接口的方式因为那样耦合度太高一个Agent的故障或阻塞可能导致整个链条崩溃。取而代之的是基于消息的异步通信模式。我选择了一个非常轻量级的Python库huey作为本地消息队列/任务队列。它的好处是支持Redis、SQLite或内存作为后端。为了极致轻量我使用了SQLite作为huey的后端这样不需要额外运行Redis服务。整个工作流是这样的用户在前端点击“运行任务”前端调用后端API。后端的“调度Agent”收到请求它不自己干活而是向huey队列中发布一系列消息任务。第一条消息crawl_task.delay(task_id, source_list)第二条消息依赖上一条完成parse_task.delay(task_id, crawl_result_id)第三条消息依赖上一条完成report_task.delay(task_id, parse_result_id)huey有一个或多个消费者进程Worker它们持续监听队列。当看到crawl_task时一个空闲的Worker就会执行“采集Agent”的代码。执行完毕后根据任务定义自动触发parse_task。每个任务执行的状态成功、失败、进行中、结果、日志都会被记录到主SQLite数据库的task_records表中。这种模式的优点是解耦Agent之间互不知晓只通过队列通信。异步前端发出请求后即可返回无需等待长时间的任务执行。重试huey内置了任务重试机制。如果网络波动导致某个爬虫任务失败可以配置自动重试几次。扩展性理论上如果采集任务非常多可以启动多个huey worker进程来并行处理提高效率。4.2 任务状态追踪与数据一致性所有任务和数据的生命周期都需要被清晰记录。我的数据库里主要有这几张核心表tasks: 存储用户定义的研究任务元数据。task_runs: 存储每次任务执行实例。每次手动或定时触发一个任务就生成一条task_run记录包含状态pending, running, success, failed、开始时间、结束时间。crawl_jobs: 关联到某个task_run存储每次采集作业的详细信息目标URL、采集参数、状态、原始HTML存储路径。parsed_data: 存储解析Agent的产出即结构化数据。每条记录都通过crawl_job_id关联到其来源。reports: 存储生成的报告文件路径和元信息。通过这种设计我们可以轻松回答以下问题“昨天那个监控任务成功了吗”“它抓到了哪些网页”“从某某网页里提取出了什么信息”“最终生成的报告在哪里” 这为调试和审计提供了极大便利。数据一致性方面我大量使用了数据库事务。例如当解析Agent成功提取出一批数据后它会在一个事务中先将这批数据插入parsed_data表然后更新对应的crawl_job状态为parsed。如果中途出错事务回滚所有更改撤销状态保持不变避免了“半成品”数据污染数据库。4.3 不可避免的踩坑与稳定性加固在实际开发和使用中会遇到各种各样的问题。以下是几个典型的“坑”及其解决方案坑一网站结构变化导致解析失败这是最常见的问题。今天还能用的XPath明天可能就因为网站改版而失效。应对策略AI辅助兜底在解析模板中优先使用AI提取基于语义理解其对页面结构变化的容忍度比固定XPath高很多。虽然成本稍高但稳定性更好。规则与AI结合对于关键字段如标题、日期可以同时配置规则提取和AI提取。规则优先如果规则提取失败或结果置信度低则自动启用AI提取并将此情况记录日志提示用户检查规则。变更监控Evidence Loom可以记录每次解析的“签名”如提取到的标题文本哈希。如果连续多次发现同一数据源的解析签名发生剧烈变化可以自动发送通知如桌面通知提醒用户“某某网站结构可能已变更请检查解析模板”。坑二网络请求的波动与反爬目标网站可能不稳定或者有速率限制、验证码等反爬措施。应对策略指数退避重试采集Agent的HTTP请求必须实现重试逻辑。第一次失败后等待1秒重试第二次失败后等待2秒第三次等待4秒……以此类推。User-Agent轮换与代理池内置一个常见的浏览器User-Agent列表每次请求随机选用。对于需要高强度采集的场景可以配置代理IP池。尊重robots.txt采集Agent在访问一个域名前应先获取并解析其robots.txt遵守其中定义的爬取延迟Crawl-delay和禁止目录。这是一个法律和道德问题Evidence Loom必须内置此功能。Playwright模拟真人操作对于复杂反爬如Cloudflare五秒盾使用Playwright等无头浏览器并模拟人的操作间隔随机等待、移动鼠标是更有效的方法。坑三AI提取的成本与效率如果完全依赖OpenAI GPT-4这类付费API频繁调用成本会很高且响应速度受网络影响。应对策略本地模型优先对于简单的字段提取如从已知结构的段落中找日期、人名完全可以先用正则表达式或基于本地小模型如spaCy的NER模型尝试失败后再fallback到大型API。提示词优化与缓存精心设计提示词让AI一次提取多个字段减少调用次数。对于相同的原始内容其AI提取结果可以缓存起来避免重复计算。支持多AI后端Evidence Loom的架构应支持配置不同的AI提供商OpenAI, Anthropic, 本地部署的Ollama等让用户可以根据任务需求和预算灵活选择。坑四长时间运行的内存与资源泄漏Evidence Loom作为桌面应用可能长时间运行内存和资源管理不当会导致应用越来越卡。应对策略进程隔离将每个耗时较长的Agent任务特别是使用Playwright的爬虫放在独立的子进程中运行。任务结束后子进程退出操作系统会回收其占用的所有资源特别是浏览器实例占用的内存。连接池与资源清理数据库连接、HTTP会话等资源必须使用连接池并在使用完毕后确保正确归还或关闭。在Python代码中务必使用with语句或try...finally块来保证资源释放。定期清理旧数据提供设置选项允许用户自动清理超过一定时间的原始HTML缓存或中间数据防止本地存储无限膨胀。通过将这些稳定性考量融入架构和代码Evidence Loom才能从一个脆弱的原型蜕变成一个能7x24小时稳定运行的生产力工具。5. 超越基础高级用法与个性化扩展当基础的信息监控流水线跑通后你可以基于Evidence Loom的可扩展架构实现更复杂、更智能的研究场景。5.1 构建自定义Agent与插件系统Evidence Loom的核心优势在于其模块化。所有Agent都是可插拔的。如果你想增加一个新功能比如从PDF白皮书中提取信息你不需要修改核心代码只需要开发一个新的Agent。创建新Agent类在agents/目录下新建一个Python文件例如pdf_agent.py。定义一个类实现标准的接口如run(input_data)方法。注册Agent在一个中心配置文件中将你的新Agent注册到系统中并指定它处理哪种类型的任务或数据例如文件后缀为.pdf的输入。在任务流中调用在创建或编辑任务流水线时你就可以在图形化界面中看到并添加这个“PDF解析”节点了。我预留了插件系统的接口。未来用户可以将自己开发的Agent打包成插件通过“导入插件”的方式与他人分享。想象一下有人开发了一个专门从财报PDF中提取财务数据的Agent另一个开发了从专利网站抓取并分析技术趋势的Agent你可以像搭积木一样将它们组合到自己的研究流水线中。5.2 智能分析与洞察生成目前的整理Agent主要做的是信息的“搬运”和“格式化”。我们可以让它变得更“智能”。情感分析在解析社区讨论如Reddit, HN时可以集成一个情感分析模型可以是本地运行的textblob或vaderSentiment自动判断对某个产品、版本更新的社区情绪是正面、负面还是中性并在报告中以可视化形式如表情符号或趋势线呈现。主题聚类与演化追踪对于长时间监控一个领域如“量子计算”积累的文本数据会很多。可以定期如每周运行一次聚类算法如TF-IDF K-Means自动发现本周讨论的新兴主题或热点并与上周的主题进行关联看出话题的演化趋势。自动生成综述摘要利用大语言模型的总结能力让报告Agent不仅罗列事实还能生成一段连贯的“本周综述”。提示词可以这样设计“请基于以下过去一周关于‘开源大模型’的十条关键动态生成一段300字左右的行业综述摘要突出主要进展和社区关注点。”5.3 数据导出与外部工具联动Evidence Loom的终点不应只是一个本地报告文件。它应该能无缝融入你现有的工作流。数据库直连Evidence Loom的所有结构化数据都存在SQLite里。你可以用任何支持SQLite的工具如DBeaver, Metabase, 甚至Excel直接打开这个数据库文件进行更复杂的查询、分析和可视化。API导出我计划为Evidence Loom的后端增加一个简单的RESTful API。这样你可以从其他脚本或应用比如你的数据看板、自动化通知系统中随时查询最新的研究数据。Webhook通知除了生成本地文件和邮件任务完成后还可以触发一个Webhook将报告内容或关键发现发送到你指定的服务器比如自动发布到团队内部的Slack频道或钉钉群。与Notion、Obsidian等集成通过它们的APIEvidence Loom可以将生成的Markdown报告直接推送并创建为新的页面或笔记实现知识管理的自动化归档。6. 开源的意义与社区共建我将Evidence Loom开源是希望它能成为一个起点而非终点。我一个人的使用场景和想象力是有限的但社区的力量是无穷的。共同应对“信息过载”市场研究、竞品分析、学术追踪、舆情监控……这些本质上都是与“信息过载”搏斗的过程。我希望Evidence Loom能成为一个可编程的、属于用户自己的“信息减负”工具。共享Agent复用智慧开源后最大的想象空间在于“Agent市场”或“模板市场”。一个用户为他所在的垂直领域比如加密货币、生物科技精心调校的一套数据源和解析模板可以分享给社区里的同行其他人一键导入即可使用省去了大量配置时间。同样一个效果出色的AI提示词、一个巧妙的反反爬策略都可以成为共享的资产。在本地守护数据隐私在云计算时代我们习惯了把数据交给SaaS服务。但有些研究涉及敏感信息或早期创意你不希望它们离开自己的设备。Evidence Loom的“本地优先”架构提供了一种选择它在提供自动化能力的同时将数据的控制权百分百交还给用户。这对于律师、记者、投资者、科研人员等群体尤为重要。轻量、可定制、可审计与那些功能庞杂、价格高昂的企业级商业软件相比Evidence Loom力求轻量、聚焦。它的代码是透明的你可以确切地知道它如何访问网络、如何处理你的数据。你可以根据自己的需求任意修改和扩展它而不会被供应商锁定。开发Evidence Loom的过程也是我对自己工作流的一次深度重构和自动化实践。它目前可能还不够完美但已经实实在在地提升了我的信息处理效率。我把这个“织布机”的蓝图和初版代码公开出来是抛砖引玉。无论是对于想学习多Agent系统设计的开发者还是对于苦苦寻找高效研究工具的从业者我都希望它能带来一些启发和实际的价值。接下来的路期待能与社区一起走下去共同编织更强大的信息处理工具。