[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"similar-AgentEra--Agently-Daily-News-Collector":3,"tool-AgentEra--Agently-Daily-News-Collector":61},[4,18,26,36,44,53],{"id":5,"name":6,"github_repo":7,"description_zh":8,"stars":9,"difficulty_score":10,"last_commit_at":11,"category_tags":12,"status":17},4358,"openclaw","openclaw\u002Fopenclaw","OpenClaw 是一款专为个人打造的本地化 AI 助手，旨在让你在自己的设备上拥有完全可控的智能伙伴。它打破了传统 AI 助手局限于特定网页或应用的束缚，能够直接接入你日常使用的各类通讯渠道，包括微信、WhatsApp、Telegram、Discord、iMessage 等数十种平台。无论你在哪个聊天软件中发送消息，OpenClaw 都能即时响应，甚至支持在 macOS、iOS 和 Android 设备上进行语音交互，并提供实时的画布渲染功能供你操控。\n\n这款工具主要解决了用户对数据隐私、响应速度以及“始终在线”体验的需求。通过将 AI 部署在本地，用户无需依赖云端服务即可享受快速、私密的智能辅助，真正实现了“你的数据，你做主”。其独特的技术亮点在于强大的网关架构，将控制平面与核心助手分离，确保跨平台通信的流畅性与扩展性。\n\nOpenClaw 非常适合希望构建个性化工作流的技术爱好者、开发者，以及注重隐私保护且不愿被单一生态绑定的普通用户。只要具备基础的终端操作能力（支持 macOS、Linux 及 Windows WSL2），即可通过简单的命令行引导完成部署。如果你渴望拥有一个懂你",349277,3,"2026-04-06T06:32:30",[13,14,15,16],"Agent","开发框架","图像","数据工具","ready",{"id":19,"name":20,"github_repo":21,"description_zh":22,"stars":23,"difficulty_score":10,"last_commit_at":24,"category_tags":25,"status":17},3808,"stable-diffusion-webui","AUTOMATIC1111\u002Fstable-diffusion-webui","stable-diffusion-webui 是一个基于 Gradio 构建的网页版操作界面，旨在让用户能够轻松地在本地运行和使用强大的 Stable Diffusion 图像生成模型。它解决了原始模型依赖命令行、操作门槛高且功能分散的痛点，将复杂的 AI 绘图流程整合进一个直观易用的图形化平台。\n\n无论是希望快速上手的普通创作者、需要精细控制画面细节的设计师，还是想要深入探索模型潜力的开发者与研究人员，都能从中获益。其核心亮点在于极高的功能丰富度：不仅支持文生图、图生图、局部重绘（Inpainting）和外绘（Outpainting）等基础模式，还独创了注意力机制调整、提示词矩阵、负向提示词以及“高清修复”等高级功能。此外，它内置了 GFPGAN 和 CodeFormer 等人脸修复工具，支持多种神经网络放大算法，并允许用户通过插件系统无限扩展能力。即使是显存有限的设备，stable-diffusion-webui 也提供了相应的优化选项，让高质量的 AI 艺术创作变得触手可及。",162132,"2026-04-05T11:01:52",[14,15,13],{"id":27,"name":28,"github_repo":29,"description_zh":30,"stars":31,"difficulty_score":32,"last_commit_at":33,"category_tags":34,"status":17},1381,"everything-claude-code","affaan-m\u002Feverything-claude-code","everything-claude-code 是一套专为 AI 编程助手（如 Claude Code、Codex、Cursor 等）打造的高性能优化系统。它不仅仅是一组配置文件，而是一个经过长期实战打磨的完整框架，旨在解决 AI 代理在实际开发中面临的效率低下、记忆丢失、安全隐患及缺乏持续学习能力等核心痛点。\n\n通过引入技能模块化、直觉增强、记忆持久化机制以及内置的安全扫描功能，everything-claude-code 能显著提升 AI 在复杂任务中的表现，帮助开发者构建更稳定、更智能的生产级 AI 代理。其独特的“研究优先”开发理念和针对 Token 消耗的优化策略，使得模型响应更快、成本更低，同时有效防御潜在的攻击向量。\n\n这套工具特别适合软件开发者、AI 研究人员以及希望深度定制 AI 工作流的技术团队使用。无论您是在构建大型代码库，还是需要 AI 协助进行安全审计与自动化测试，everything-claude-code 都能提供强大的底层支持。作为一个曾荣获 Anthropic 黑客大奖的开源项目，它融合了多语言支持与丰富的实战钩子（hooks），让 AI 真正成长为懂上",140436,2,"2026-04-05T23:32:43",[14,13,35],"语言模型",{"id":37,"name":38,"github_repo":39,"description_zh":40,"stars":41,"difficulty_score":32,"last_commit_at":42,"category_tags":43,"status":17},2271,"ComfyUI","Comfy-Org\u002FComfyUI","ComfyUI 是一款功能强大且高度模块化的视觉 AI 引擎，专为设计和执行复杂的 Stable Diffusion 图像生成流程而打造。它摒弃了传统的代码编写模式，采用直观的节点式流程图界面，让用户通过连接不同的功能模块即可构建个性化的生成管线。\n\n这一设计巧妙解决了高级 AI 绘图工作流配置复杂、灵活性不足的痛点。用户无需具备编程背景，也能自由组合模型、调整参数并实时预览效果，轻松实现从基础文生图到多步骤高清修复等各类复杂任务。ComfyUI 拥有极佳的兼容性，不仅支持 Windows、macOS 和 Linux 全平台，还广泛适配 NVIDIA、AMD、Intel 及苹果 Silicon 等多种硬件架构，并率先支持 SDXL、Flux、SD3 等前沿模型。\n\n无论是希望深入探索算法潜力的研究人员和开发者，还是追求极致创作自由度的设计师与资深 AI 绘画爱好者，ComfyUI 都能提供强大的支持。其独特的模块化架构允许社区不断扩展新功能，使其成为当前最灵活、生态最丰富的开源扩散模型工具之一，帮助用户将创意高效转化为现实。",107662,"2026-04-03T11:11:01",[14,15,13],{"id":45,"name":46,"github_repo":47,"description_zh":48,"stars":49,"difficulty_score":10,"last_commit_at":50,"category_tags":51,"status":17},4292,"Deep-Live-Cam","hacksider\u002FDeep-Live-Cam","Deep-Live-Cam 是一款专注于实时换脸与视频生成的开源工具，用户仅需一张静态照片，即可通过“一键操作”实现摄像头画面的即时变脸或制作深度伪造视频。它有效解决了传统换脸技术流程繁琐、对硬件配置要求极高以及难以实时预览的痛点，让高质量的数字内容创作变得触手可及。\n\n这款工具不仅适合开发者和技术研究人员探索算法边界，更因其极简的操作逻辑（仅需三步：选脸、选摄像头、启动），广泛适用于普通用户、内容创作者、设计师及直播主播。无论是为了动画角色定制、服装展示模特替换，还是制作趣味短视频和直播互动，Deep-Live-Cam 都能提供流畅的支持。\n\n其核心技术亮点在于强大的实时处理能力，支持口型遮罩（Mouth Mask）以保留使用者原始的嘴部动作，确保表情自然精准；同时具备“人脸映射”功能，可同时对画面中的多个主体应用不同面孔。此外，项目内置了严格的内容安全过滤机制，自动拦截涉及裸露、暴力等不当素材，并倡导用户在获得授权及明确标注的前提下合规使用，体现了技术发展与伦理责任的平衡。",88924,"2026-04-06T03:28:53",[14,15,13,52],"视频",{"id":54,"name":55,"github_repo":56,"description_zh":57,"stars":58,"difficulty_score":32,"last_commit_at":59,"category_tags":60,"status":17},3704,"NextChat","ChatGPTNextWeb\u002FNextChat","NextChat 是一款轻量且极速的 AI 助手，旨在为用户提供流畅、跨平台的大模型交互体验。它完美解决了用户在多设备间切换时难以保持对话连续性，以及面对众多 AI 模型不知如何统一管理的痛点。无论是日常办公、学习辅助还是创意激发，NextChat 都能让用户随时随地通过网页、iOS、Android、Windows、MacOS 或 Linux 端无缝接入智能服务。\n\n这款工具非常适合普通用户、学生、职场人士以及需要私有化部署的企业团队使用。对于开发者而言，它也提供了便捷的自托管方案，支持一键部署到 Vercel 或 Zeabur 等平台。\n\nNextChat 的核心亮点在于其广泛的模型兼容性，原生支持 Claude、DeepSeek、GPT-4 及 Gemini Pro 等主流大模型，让用户在一个界面即可自由切换不同 AI 能力。此外，它还率先支持 MCP（Model Context Protocol）协议，增强了上下文处理能力。针对企业用户，NextChat 提供专业版解决方案，具备品牌定制、细粒度权限控制、内部知识库整合及安全审计等功能，满足公司对数据隐私和个性化管理的高标准要求。",87618,"2026-04-05T07:20:52",[14,35],{"id":62,"github_repo":63,"name":64,"description_en":65,"description_zh":66,"ai_summary_zh":66,"readme_en":67,"readme_zh":68,"quickstart_zh":69,"use_case_zh":70,"hero_image_url":71,"owner_login":72,"owner_name":72,"owner_avatar_url":73,"owner_bio":74,"owner_company":75,"owner_location":75,"owner_email":76,"owner_twitter":77,"owner_website":75,"owner_url":78,"languages":79,"stars":88,"forks":89,"last_commit_at":90,"license":91,"difficulty_score":32,"env_os":74,"env_gpu":92,"env_ram":92,"env_deps":93,"category_tags":98,"github_topics":99,"view_count":32,"oss_zip_url":75,"oss_zip_packed_at":75,"status":17,"created_at":107,"updated_at":108,"faqs":109,"releases":138},4307,"AgentEra\u002FAgently-Daily-News-Collector","Agently-Daily-News-Collector","An open-source LLM based automatically daily news collecting workflow showcase powered by Agently AI application development framework.","Agently-Daily-News-Collector 是一款基于大语言模型的开源自动化新闻采集工作流，旨在帮助用户快速生成多栏目的每日新闻简报。只需输入一个主题，它便能自动完成从搜索、筛选、浏览网页到内容摘要和最终报告组装的全过程，并输出结构清晰的 Markdown 文档。\n\n该工具主要解决了传统新闻收集过程中信息分散、人工整理耗时费力的问题，将复杂的调研步骤整合为一条流畅的自动化流水线。它特别适合开发者和技术研究人员使用，尤其是那些希望探索 AI Agent 编排、构建自定义信息采集系统或需要高效追踪特定领域动态的用户。\n\n其核心技术亮点在于采用了最新的 Agently v4 框架，利用 `TriggerFlow` 实现了端到端的流程编排。项目架构设计高度模块化，将搜索与浏览等工具层、提示词模板以及业务逻辑分离，使得各部分可独立演进或替换。此外，它支持通过环境变量灵活配置模型参数，兼容各类 OpenAI 接口，既方便本地调试，也易于部署扩展。对于想要学习如何构建复杂 AI 工作流的开发者而言，这是一个极具参考价值的实战范例。","# Agently Daily News Collector v4\n\nAgently Daily News Collector has been rewritten on top of **Agently v4** and now uses:\n\n- `TriggerFlow` for the end-to-end pipeline\n- Agently v4 built-in `Search` and `Browse` tools\n- structured output contracts instead of the old v3 workflow API\n\n> Version constraint: this project requires **Agently v4.0.8.3 or newer**. The current implementation uses `TriggerFlow sub flow` to organize per-column pipelines, so earlier v4 releases are not compatible with the workflow structure used here.\n\nThe previous Agently v3 project has been archived under [`.\u002Fv3`](.\u002Fv3).\n\n## Features\n\n- Input a topic and generate a multi-column news briefing automatically\n- Search, shortlist, browse, summarize, and assemble stories in one flow\n- Save the final report as Markdown under `.\u002Foutputs`\n- Keep prompt templates in `.\u002Fprompts` for easy editing\n- Keep an independent `.\u002Ftools` layer so search\u002Fbrowse can be replaced without touching the main workflow\n- Keep flow construction in `.\u002Fworkflow` so orchestration can evolve independently from collector logic\n\n## Quick Start\n\n1. Install dependencies:\n\n```bash\npip install -r requirements.txt\n```\n\nIf you install Agently manually, make sure you use at least:\n\n```bash\npip install \"agently>=4.0.8.3\"\n```\n\n2. Edit [`SETTINGS.yaml`](.\u002FSETTINGS.yaml):\n\n- Keep the model block as environment placeholders\n- Export the required environment variables:\n\n```bash\nexport AGENTLY_NEWS_BASE_URL=\"https:\u002F\u002Fapi.openai.com\u002Fv1\"\nexport AGENTLY_NEWS_MODEL=\"gpt-4.1-mini\"\nexport AGENTLY_NEWS_API_KEY=\"your_api_key\"\n```\n\n- Or put them in a local `.env` file:\n\n```dotenv\nAGENTLY_NEWS_BASE_URL=https:\u002F\u002Fapi.openai.com\u002Fv1\nAGENTLY_NEWS_MODEL=gpt-4.1-mini\nAGENTLY_NEWS_API_KEY=your_api_key\n```\n\n- Adjust language \u002F search \u002F concurrency settings if needed\n- If your OpenAI-compatible endpoint does not require authentication, you can leave `AGENTLY_NEWS_API_KEY` unset and the project will skip `auth`.\n\n3. Run:\n\n```bash\npython app.py\n```\n\nOr pass a topic directly:\n\n```bash\npython app.py \"AI agents\"\n```\n\n## Project Structure\n\n```text\n.\n├── app.py\n├── news_collector\u002F\n├── tools\u002F\n├── workflow\u002F\n├── prompts\u002F\n├── outputs\u002F\n├── logs\u002F\n└── v3\u002F\n```\n\n## Important v3 -> v4 Changes\n\nThe business chain is still roughly:\n\n`outline -> search -> pick -> browse + summarize -> write column -> render markdown`\n\nWhat changed is the engineering shape around that chain.\n\n### Project-level changes\n\n- The old v3 project used a main workflow plus a nested column workflow under `.\u002Fworkflows`, with custom `search.py` \u002F `browse.py` helpers and storage-style state passing.\n- The v4 project separates responsibilities more clearly:\n  - `news_collector\u002F`: app\u002Fintegration layer\n  - `workflow\u002F`: parent flow, column sub flow, and concrete chunk logic\n  - `tools\u002F`: search\u002Fbrowse adapter layer\n  - `prompts\u002F`: structured prompt contracts\n- Model configuration is no longer hardcoded in Python. It now uses `${ENV.xxx}` placeholders from `SETTINGS.yaml`, so deployment and local switching are simpler.\n- Tool wiring is no longer buried inside workflow code. Search, browse, and logger are injected as TriggerFlow runtime resources, which makes the workflow easier to replace or test.\n- The workflow plan is now closer to the business boundary:\n  - parent flow: `prepare_request -> generate_outline -> for_each(column) -> render_report`\n  - column sub flow: `search -> pick -> summarize -> write_column`\n  - the `summarize` stage inside the column flow is further pushed down into a summary sub flow, where TriggerFlow handles fan-out and collection directly instead of leaving `asyncio.gather` in business code\n  - this keeps the parent focused on report orchestration and the child focused on one column lifecycle\n  - the immediate value of `sub flow` here is that the column pipeline becomes a reusable, independently evolvable workflow unit instead of staying buried inside one oversized parent chunk\n\n### Agently v4 features used here\n\n- **TriggerFlow orchestration**\n  - Replaces the old v3 workflow style with a more explicit flow graph (`to`, `for_each`, `sub flow`, branching-ready composition).\n  - Unlike the old v3 Workflow chain, TriggerFlow here runs columns concurrently and also summarizes picked stories concurrently within each column.\n  - Meaning for this project: the end-to-end news pipeline is easier to inspect, evolve, and split into chunks without mixing orchestration with business logic, while the parent report flow and the per-column pipeline can now be modeled directly as parent\u002Fchild flows instead of one oversized chunk.\n- **Sub flow composition**\n  - The project can now extract a naturally repeated business pipeline, “build one column”, into its own TriggerFlow and invoke it repeatedly from the parent flow inside `for_each(column)`.\n  - Meaning for this project:\n    - the parent flow stays focused on report-level orchestration\n    - the column pipeline can be tested, visualized, and exported independently\n    - future variants such as “briefing column”, “deep-dive column”, or “regional column” can reuse or derive from the child flow instead of cloning parent-flow nodes\n    - `capture \u002F write_back` makes the boundary between parent and child explicit for input, state, and resources\n- **Structured output contracts**\n  - YAML prompts now define output schema directly for outline generation, news picking, summarizing, and column writing.\n  - Meaning for this project: much less handwritten parsing glue, clearer interfaces between steps, and easier prompt iteration.\n- **Built-in Search \u002F Browse tools**\n  - The project now defaults to Agently v4 built-in tool implementations instead of the old project-local helpers.\n  - Meaning for this project: less custom infrastructure code, and users can still swap implementations through `.\u002Ftools` without rewriting the workflow.\n- **Runtime resources and state namespaces**\n  - TriggerFlow runtime resources are used to inject logger\u002Fsearch\u002Fbrowse dependencies, while runtime state stores execution data such as request, outline, and intermediate results.\n  - Meaning for this project: dependency wiring and execution state are separated cleanly, which keeps chunk code thinner and more maintainable.\n- **Environment-aware settings**\n  - Agently v4 `set_settings(..., auto_load_env=True)` works directly with `${ENV.xxx}` placeholders.\n  - Meaning for this project: model endpoint, model name, and API key can be switched by environment instead of editing code or committing secrets.\n\n### Overall effect on this project\n\n- The core product behavior remains familiar to v3 users, but the project now has a cleaner app\u002Fworkflow\u002Ftools\u002Fprompts split.\n- More logic is expressed in Agently-native capabilities instead of project-specific glue code.\n- True concurrency is now part of the default execution model. The v3 version was effectively serial, while the v4 version can process columns and per-column summaries in parallel through TriggerFlow.\n- Replacing tools, adjusting prompts, or evolving workflow steps is now lower-risk than in the old v3 layout, and the overall orchestration shape is again aligned with the original “main flow + column flow” mental model.\n- It also means workflow evolution can happen by layer: report-level changes stay in the parent flow, while column-level changes stay in the sub flow instead of forcing both to change together.\n\n## Notes\n\n- Python `>=3.10` is required because Agently v4 requires it.\n- This project requires Agently `>=4.0.8.3`.\n- Model settings now use Agently v4 `auto_load_env=True` with `${ENV.xxx}` placeholders.\n- `tools\u002F` defaults to Agently v4 built-in implementations, but you can replace the factories there with your own tools.\n- `workflow\u002F` is now split by business boundary into the parent flow, the column sub flow, report-level chunks, and column-level chunks.\n- `news_collector\u002F` acts as the app\u002Fintegration layer for configuration, model wiring, and CLI entry support.\n- The current sample [`SETTINGS.yaml`](.\u002FSETTINGS.yaml) enables `BROWSE.enable_playwright: true` by default because many news pages need a real browser to return usable content.\n- If you do not want to install Playwright, set `BROWSE.enable_playwright` to `false` manually, but expect weaker browse quality on dynamic or protected sites.\n- The settings loader keeps basic compatibility with the old v3 keys such as `MODEL_PROVIDER`, `MODEL_URL`, `MODEL_AUTH`, `MODEL_OPTIONS`, `MAX_COLUMN_NUM`, and `USE_CUSTOMIZE_OUTLINE`.\n","# Agently 每日新闻收集器 v4\n\nAgently 每日新闻收集器已在 **Agently v4** 的基础上重写，现使用：\n\n- `TriggerFlow` 作为端到端流水线\n- Agently v4 内置的 `Search` 和 `Browse` 工具\n- 结构化输出契约，而非旧版 v3 的工作流 API\n\n> 版本约束：本项目需要 **Agently v4.0.8.3 或更高版本**。当前实现使用 `TriggerFlow 子流程` 来组织每列的流水线，因此较早的 v4 版本与此处使用的工作流结构不兼容。\n\n之前的 Agently v3 项目已被归档至 [`.\u002Fv3`](.\u002Fv3)。\n\n## 功能特性\n\n- 输入主题，自动生成多列新闻简报\n- 在一个流程中完成搜索、初选、浏览、摘要和故事组装\n- 将最终报告保存为 Markdown 格式，存放在 `.\u002Foutputs`\n- 提示模板置于 `.\u002Fprompts` 目录下，便于编辑\n- 保持独立的 `.\u002Ftools` 层，以便在不触及主工作流的情况下替换搜索\u002F浏览组件\n- 流程构建逻辑位于 `.\u002Fworkflow`，使编排部分能够独立于收集逻辑演进\n\n## 快速开始\n\n1. 安装依赖：\n\n```bash\npip install -r requirements.txt\n```\n\n如果您手动安装 Agently，请确保至少使用以下命令：\n\n```bash\npip install \"agently>=4.0.8.3\"\n```\n\n2. 编辑 [`SETTINGS.yaml`](.\u002FSETTINGS.yaml)：\n\n- 保留模型配置块为环境占位符\n- 导出所需的环境变量：\n\n```bash\nexport AGENTLY_NEWS_BASE_URL=\"https:\u002F\u002Fapi.openai.com\u002Fv1\"\nexport AGENTLY_NEWS_MODEL=\"gpt-4.1-mini\"\nexport AGENTLY_NEWS_API_KEY=\"your_api_key\"\n```\n\n- 或将其放入本地 `.env` 文件中：\n\n```dotenv\nAGENTLY_NEWS_BASE_URL=https:\u002F\u002Fapi.openai.com\u002Fv1\nAGENTLY_NEWS_MODEL=gpt-4.1-mini\nAGENTLY_NEWS_API_KEY=your_api_key\n```\n\n- 如有需要，可调整语言、搜索和并发设置\n- 如果您的 OpenAI 兼容端点无需认证，您可以将 `AGENTLY_NEWS_API_KEY` 留空，项目将跳过认证步骤。\n\n3. 运行：\n\n```bash\npython app.py\n```\n\n或直接传入主题：\n\n```bash\npython app.py \"AI agents\"\n```\n\n## 项目结构\n\n```text\n.\n├── app.py\n├── news_collector\u002F\n├── tools\u002F\n├── workflow\u002F\n├── prompts\u002F\n├── outputs\u002F\n├── logs\u002F\n└── v3\u002F\n```\n\n## v3 到 v4 的重要变更\n\n业务链大致仍为：\n\n`概要 -> 搜索 -> 选择 -> 浏览 + 摘要 -> 撰写专栏 -> 渲染 Markdown`\n\n变化主要体现在围绕该链条的工程架构上。\n\n### 项目层面的变化\n\n- 旧版 v3 项目采用主工作流，并在 `.\u002Fworkflows` 下嵌套专栏工作流，辅以自定义的 `search.py` \u002F `browse.py` 辅助函数及存储式的状态传递。\n- v4 项目则更清晰地划分了职责：\n  - `news_collector\u002F`：应用\u002F集成层\n  - `workflow\u002F`：父流程、专栏子流程及具体任务逻辑\n  - `tools\u002F`：搜索\u002F浏览适配层\n  - `prompts\u002F`：结构化提示契约\n- 模型配置不再硬编码在 Python 中，而是使用 `SETTINGS.yaml` 中的 `${ENV.xxx}` 占位符，从而简化部署和本地切换。\n- 工具的连接不再嵌入工作流代码中。搜索、浏览和日志记录器被注入为 TriggerFlow 的运行时资源，使得工作流更易于替换或测试。\n- 工作流设计更加贴近业务边界：\n  - 父流程：`准备请求 -> 生成概要 -> 遍历每一列 -> 渲染报告`\n  - 专栏子流程：`搜索 -> 选择 -> 摘要 -> 撰写专栏`\n  - 专栏流程中的 `摘要` 阶段进一步下沉为摘要子流程，由 TriggerFlow 直接处理分流与汇总，而非在业务代码中使用 `asyncio.gather`。\n  - 这样可以使父流程专注于报告编排，而子流程专注于单个专栏的生命周期。\n  - 使用 `子流程` 的直接好处是，专栏流水线成为一个可复用、可独立演进的工作流单元，而不必深埋在一个庞大的父流程中。\n\n### 此处使用的 Agently v4 特性\n\n- **TriggerFlow 编排**\n  - 替代了旧版 v3 的工作流风格，采用更为明确的流程图（`to`、`for_each`、`sub flow`、支持分支的组合）。\n  - 与旧版 v3 工作流链不同，TriggerFlow 在这里并行处理各列，并在每列内部并行摘要已选故事。\n  - 对本项目而言：端到端新闻流水线更易于检查、演进和拆分，而不会将编排逻辑与业务逻辑混杂；同时，父报告流程和每列流水线现在可以直接建模为父子流程，而非一个巨大的整体。\n- **子流程组合**\n  - 项目现在可以将自然重复的业务流程“构建一列”提取出来，形成独立的 TriggerFlow，并在父流程中通过 `for_each(column)` 不断调用。\n  - 对本项目而言：\n    - 父流程专注于报告级别的编排\n    - 专栏流水线可以独立测试、可视化和导出\n    - 未来的变体，如“简报专栏”、“深度专栏”或“区域专栏”，都可以复用或派生自子流程，而不必复制父流程节点\n    - `capture \u002F write_back` 使父流程与子流程之间的输入、状态和资源边界更加清晰\n- **结构化输出契约**\n  - YAML 提示现在直接定义了概要生成、新闻选择、摘要和专栏撰写的输出模式。\n  - 对本项目而言：减少了大量手工解析代码，步骤间的接口更加清晰，提示迭代也更加容易。\n- **内置搜索\u002F浏览工具**\n  - 项目现在默认使用 Agently v4 内置的工具实现，而非旧版项目中的本地辅助工具。\n  - 对本项目而言：减少了自定义基础设施代码，用户仍可通过 `.\u002Ftools` 更换实现方式，而无需重写工作流。\n- **运行时资源与状态命名空间**\n  - TriggerFlow 的运行时资源用于注入日志记录器、搜索和浏览等依赖项，而运行时状态则存储执行数据，如请求、概要和中间结果。\n  - 对本项目而言：依赖关系的配置与执行状态被清晰分离，从而使各个模块的代码更加简洁且易于维护。\n- **环境感知的配置**\n  - Agenty v4 的 `set_settings(..., auto_load_env=True)` 可直接与 `${ENV.xxx}` 占位符配合使用。\n  - 对本项目而言：模型端点、模型名称和 API 密钥可以通过环境变量切换，而无需修改代码或提交敏感信息。\n\n### 对该项目的整体影响\n\n- 核心产品行为对 v3 用户来说依然熟悉，但项目现在采用了更清晰的“应用\u002F工作流\u002F工具\u002F提示词”分离架构。\n- 更多逻辑被表达为 Agently 原生能力，而非项目特定的胶水代码。\n- 真正的并发现在成为默认执行模型的一部分。v3 版本实际上是串行的，而 v4 版本可以通过 TriggerFlow 并行处理列数据及每列的汇总。\n- 替换工具、调整提示词或演进工作流步骤的风险，相比旧版 v3 布局已显著降低；整体编排结构也重新契合最初的“主流程 + 列流程”思维模型。\n- 这也意味着工作流的演进可以分层进行：报表级别的变更保留在父流程中，而列级别的变更则保留在子流程中，无需强制两者同时改动。\n\n## 注意事项\n\n- 需要 Python `>=3.10`，因为 Agently v4 要求使用该版本。\n- 本项目需要 Agently `>=4.0.8.3`。\n- 模型设置现在使用 Agently v4 的 `auto_load_env=True`，并采用 `${ENV.xxx}` 占位符。\n- `tools\u002F` 默认使用 Agently v4 内置实现，但你可以用自定义工具替换其中的工厂方法。\n- `workflow\u002F` 现在按业务边界拆分为父流程、列子流程、报表级任务块和列级任务块。\n- `news_collector\u002F` 充当应用\u002F集成层，负责配置、模型对接以及 CLI 入口支持。\n- 当前示例中的 [`SETTINGS.yaml`](.\u002FSETTINGS.yaml) 默认启用了 `BROWSE.enable_playwright: true`，因为许多新闻页面需要真实浏览器才能返回可用内容。\n- 如果你不想安装 Playwright，请手动将 `BROWSE.enable_playwright` 设置为 `false`，但请注意，在动态或受保护的网站上，浏览质量可能会较差。\n- 设置加载器仍与旧版 v3 的键保持基本兼容，例如 `MODEL_PROVIDER`、`MODEL_URL`、`MODEL_AUTH`、`MODEL_OPTIONS`、`MAX_COLUMN_NUM` 和 `USE_CUSTOMIZE_OUTLINE`。","# Agently Daily News Collector 快速上手指南\n\n## 环境准备\n\n在开始之前，请确保您的开发环境满足以下要求：\n\n*   **操作系统**：Linux \u002F macOS \u002F Windows\n*   **Python 版本**：>= 3.10（Agently v4 强制要求）\n*   **核心依赖**：Agently >= 4.0.8.3\n*   **浏览器引擎（可选但推荐）**：若需抓取动态新闻页面，建议安装 Playwright。\n    *   安装命令：`playwright install`\n    *   *注：若不使用 Playwright，需在配置中关闭相关选项，但可能导致部分动态网站抓取失败。*\n\n## 安装步骤\n\n1.  **克隆项目并安装依赖**\n    推荐使用国内镜像源加速安装过程：\n\n    ```bash\n    pip install -r requirements.txt -i https:\u002F\u002Fpypi.tuna.tsinghua.edu.cn\u002Fsimple\n    ```\n\n    如果手动安装 Agently，请确保版本不低于 4.0.8.3：\n\n    ```bash\n    pip install \"agently>=4.0.8.3\" -i https:\u002F\u002Fpypi.tuna.tsinghua.edu.cn\u002Fsimple\n    ```\n\n2.  **配置环境变量**\n    编辑项目根目录下的 [`SETTINGS.yaml`](.\u002FSETTINGS.yaml) 文件，模型配置部分保留 `${ENV.xxx}` 占位符即可。\n    \n    接着，您需要设置大模型相关的环境变量。您可以选择以下任一方式：\n\n    *   **方式 A：导出环境变量（临时生效）**\n        ```bash\n        export AGENTLY_NEWS_BASE_URL=\"https:\u002F\u002Fapi.openai.com\u002Fv1\"\n        export AGENTLY_NEWS_MODEL=\"gpt-4.1-mini\"\n        export AGENTLY_NEWS_API_KEY=\"your_api_key\"\n        ```\n        *(国内用户可将 `BASE_URL` 替换为兼容 OpenAI 协议的国内中转地址)*\n\n    *   **方式 B：创建 `.env` 文件（推荐，持久生效）**\n        在项目根目录创建 `.env` 文件并填入以下内容：\n        ```dotenv\n        AGENTLY_NEWS_BASE_URL=https:\u002F\u002Fapi.openai.com\u002Fv1\n        AGENTLY_NEWS_MODEL=gpt-4.1-mini\n        AGENTLY_NEWS_API_KEY=your_api_key\n        ```\n\n3.  **调整高级设置（可选）**\n    如需修改语言、并发数或关闭 Playwright，可在 [`SETTINGS.yaml`](.\u002FSETTINGS.yaml) 中调整对应字段。\n    *   若不安装 Playwright，请将 `BROWSE.enable_playwright` 设为 `false`。\n\n## 基本使用\n\n配置完成后，即可运行新闻收集程序。生成的报告将以 Markdown 格式保存至 `.\u002Foutputs` 目录。\n\n*   **运行默认主题**\n    ```bash\n    python app.py\n    ```\n\n*   **指定特定主题生成简报**\n    ```bash\n    python app.py \"AI agents\"\n    ```\n\n程序将自动执行搜索、筛选、浏览、摘要及多栏目报告组装流程。","某科技媒体编辑每天需要为“人工智能代理”专栏快速整理全球最新进展，以便在晨会前产出深度简报。\n\n### 没有 Agently-Daily-News-Collector 时\n- 编辑需手动在多个搜索引擎和新闻网站间反复切换，耗时数小时筛选相关度高的文章，极易遗漏关键信息。\n- 阅读大量英文原文并人工摘要不仅效率低下，还容易因疲劳导致核心观点提炼不准或出现理解偏差。\n- 将零散的摘要整合成结构化的多栏目报告时，格式调整繁琐，且难以保证每日输出风格的一致性。\n- 一旦搜索源网站改版或需要更换大模型接口，必须修改大量硬编码的脚本，维护成本极高且容易出错。\n\n### 使用 Agently-Daily-News-Collector 后\n- 只需输入\"AI agents\"主题，工具自动调用内置搜索与浏览组件，端到端完成从检索、初筛到精读的全流程，分钟级获取全球资讯。\n- 基于 LLM 自动对精选文章进行多维度总结，精准提取核心论点，彻底解放人工阅读负担并确保信息准确度。\n- 直接生成排版精美的 Markdown 格式多栏目简报，预设的提示词模板确保每日报告结构清晰、风格统一，可直接发布。\n- 凭借独立的工具层与工作流设计，替换搜索源或切换大模型仅需修改配置文件，无需触动核心业务逻辑，灵活适应技术迭代。\n\nAgently-Daily-News-Collector 将原本耗时数小时的人工情报收集工作转化为自动化流水线，让内容创作者专注于深度洞察而非信息搬运。","https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002FAgentEra_Agently-Daily-News-Collector_97b51c6b.png","AgentEra","https:\u002F\u002Foss.gittoolsai.com\u002Favatars\u002FAgentEra_0455c814.png","",null,"developer@agently.tech","AgentlyTech","https:\u002F\u002Fgithub.com\u002FAgentEra",[80,84],{"name":81,"color":82,"percentage":83},"Python","#3572A5",99.9,{"name":85,"color":86,"percentage":87},"Dockerfile","#384d54",0.1,608,100,"2026-04-01T08:37:28","Apache-2.0","未说明",{"notes":94,"python":95,"dependencies":96},"该项目主要依赖大语言模型 API（如 OpenAI），而非本地 GPU 推理。默认配置启用了 Playwright 用于浏览动态新闻页面，若不需要可手动关闭，但可能影响部分网站的内容获取质量。环境变量需配置模型地址、名称及 API Key。",">=3.10",[97],"agently>=4.0.8.3",[35,13],[100,101,102,103,104,105,106],"llm-agent","llm-agents","llm-application","llm-apps","news","news-agent","search-agent","2026-03-27T02:49:30.150509","2026-04-06T17:07:29.132052",[110,115,120,125,129,134],{"id":111,"question_zh":112,"answer_zh":113,"source_url":114},19612,"在使用 AzureOpenAI 或 OpenAI 时遇到 'string indices must be integers' 错误，导致新闻筛选失败怎么办？","这是一个已知问题。AzureOpenAI 的 JSON 格式设置在要求模型生成列表（list）时，经常会错误地将其转换为单项字典，从而导致解析错误。\n解决方案：在即将发布的版本（如 3.3.1.0）中，我们将移除请求中的 JSON 格式参数，仅依靠 Agently 的提示词（Prompt）来引导模型生成列表。根据社区测试，不使用 JSON 格式参数的正确率仍可保持在 90% 以上。在此之前，建议检查模型输出或等待版本更新。","https:\u002F\u002Fgithub.com\u002FAgentEra\u002FAgently-Daily-News-Collector\u002Fissues\u002F14",{"id":116,"question_zh":117,"answer_zh":118,"source_url":119},19613,"如何在 Workflow 中嵌套调用另一个 Workflow（例如使用 .start()）时避免 'asyncio.run() cannot be called from a running event loop' 错误？","该问题已在最新版本 3.3.1.2 中得到完全修复。新版本适配了当前的表达方式，现在支持在 workflow 里直接使用 .start() 方法来嵌套调用另一个 workflow，无需额外处理事件循环冲突。请升级您的 Agently 库至 3.3.1.2 或更高版本。","https:\u002F\u002Fgithub.com\u002FAgentEra\u002FAgently-Daily-News-Collector\u002Fissues\u002F10",{"id":121,"question_zh":122,"answer_zh":123,"source_url":124},19614,"运行程序时出现 'NoneType' object is not iterable 错误，且搜索到的新闻数量为 0，是什么原因？","这通常是由于大模型单次输出的不稳定性导致的，在当前技术阶段较难完全避免。如果日志显示模型没有正常输出内容（而非输出了非 JSON 格式的内容），则可能是模型生成过程中断或未返回预期数据。\n建议：\n1. 重新尝试运行，有时重试即可成功（有用户反馈上周失败但今天正常）。\n2. 检查模型服务状态及网络连接。\n3. 若问题持续，需详细检查模型输出日志以确认具体失败原因。","https:\u002F\u002Fgithub.com\u002FAgentEra\u002FAgently-Daily-News-Collector\u002Fissues\u002F16",{"id":126,"question_zh":127,"answer_zh":128,"source_url":114},19615,"如何开启调试模式以观察模型生成过程中的详细数据和错误信息？","您可以通过修改配置文件来开启调试模式。具体步骤如下：\n1. 打开项目根目录下的 `SETTINGS.yaml` 文件。\n2. 找到 `IS_DEBUG` 配置项。\n3. 将其值设置为 `true`。\n保存后重新运行程序，控制台将输出完整的请求数据（Request Data）和模型交互过程，帮助您定位是在哪个环节（如生成大纲、筛选新闻等）出现了问题。",{"id":130,"question_zh":131,"answer_zh":132,"source_url":133},19616,"默认的新闻收集时间范围是多久？是否支持按周、双周或月度生成新闻摘要？","是的，项目已支持自定义新闻收集的时间范围。除了默认的每日新闻（Daily），现在还可以配置为每周（Weekly）、双周（Bi-weekly）或每月（Monthly）生成新闻摘要。该功能已在最近的代码提交中更新，请确保您的代码库已同步到最新版本以使用此功能。","https:\u002F\u002Fgithub.com\u002FAgentEra\u002FAgently-Daily-News-Collector\u002Fissues\u002F15",{"id":135,"question_zh":136,"answer_zh":137,"source_url":119},19617,"MODEL_PROVIDER 设置为 OAIClient 时，支持哪些兼容 OpenAI 格式的本地模型？","当设置 `MODEL_PROVIDER: OAIClient` 时，默认使用 OpenAI 格式的兼容客户端。该客户端设计用于适配标准的 OpenAI API 以及各类兼容 OpenAI 格式的本地部署模型（如通过 Ollama, LocalAI, vLLM 等部署的模型）。只要本地模型的服务端点遵循 OpenAI 的 API 规范（包括聊天补全接口等），即可通过配置对应的 base_url 和 api_key 进行连接和使用。",[]]