Agently-Daily-News-Collector

AgentEraApache-2.0更新放缓

基于 Agently 框架搭建的每日新闻自动采集工作流示例,用 LLM Agent 完成搜索与汇总,适合参考如何编排多步 Agent 应用。

An open-source LLM based automatically daily news collecting workflow showcase powered by Agently AI application development framework.

暂无版本645star114fork同步于 2026-11-07 07:29 UTC

怎么上手

由 README 提炼,执行前请确认
pip install -r requirements.txt
python app.py "AI agents"
硬件要求按 README 说明

README 未说明显存或 GPU 要求;需 Python >=3.10,模型通过 OpenAI 兼容 API 调用,默认启用 Playwright 浏览网页

下载:源码 zip·GitHub Releases(安装包)本站不镜像安装包

项目说明

由 README 自动翻译提炼

基于 Agently v4 的每日新闻采集工作流示例,输入主题即可自动生成多栏目新闻简报

基于 Agently 框架搭建的每日新闻自动采集工作流示例,用 LLM Agent 完成搜索与汇总,适合参考如何编排多步 Agent 应用。

核心能力

  • 用 TriggerFlow 编排搜索、筛选、浏览、摘要、成稿全流程
  • 父流程与栏目子流程分层,栏目与摘要并发执行
  • YAML 提示词直接定义结构化输出契约,减少手写解析
  • 内置 Search/Browse 工具,可在 tools 层替换实现
  • 报告以 Markdown 保存到 ./outputs,提示词集中在 ./prompts

容易踩的坑

必须使用 Agently >=4.0.8.3,旧版 v4 与当前 sub flow 结构不兼容;需先配置 AGENTLY_NEWS_BASE_URL、AGENTLY_NEWS_MODEL、AGENTLY_NEWS_API_KEY 环境变量或 .env;默认开启 BROWSE.enable_playwright,未安装 Playwright 需手动设为 false,否则动态站点抓取质量下降

内容由模型根据 README 生成,可能不完整或不准确,以官方文档为准。看原文 README

最近发版

0 个版本

暂无 release 数据(可能没有发版,或尚未同步)。

用户点评

登录用户的真实使用记录,可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译

    Agently Daily News Collector v4

    Agently Daily News Collector has been rewritten on top of Agently v4 and now uses:

    • TriggerFlow for the end-to-end pipeline
    • Agently v4 built-in Search and Browse tools
    • structured output contracts instead of the old v3 workflow API

    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.

    The previous Agently v3 project has been archived under ./v3.

    Features

    • Input a topic and generate a multi-column news briefing automatically
    • Search, shortlist, browse, summarize, and assemble stories in one flow
    • Save the final report as Markdown under ./outputs
    • Keep prompt templates in ./prompts for easy editing
    • Keep an independent ./tools layer so search/browse can be replaced without touching the main workflow
    • Keep flow construction in ./workflow so orchestration can evolve independently from collector logic

    Quick Start

    1. Install dependencies:
    pip install -r requirements.txt
    

    If you install Agently manually, make sure you use at least:

    pip install "agently>=4.0.8.3"
    
    1. Edit SETTINGS.yaml:
    • Keep the model block as environment placeholders
    • Export the required environment variables:
    export AGENTLY_NEWS_BASE_URL="https://api.openai.com/v1"
    export AGENTLY_NEWS_MODEL="gpt-4.1-mini"
    export AGENTLY_NEWS_API_KEY="your_api_key"
    
    • Or put them in a local .env file:
    AGENTLY_NEWS_BASE_URL=https://api.openai.com/v1
    AGENTLY_NEWS_MODEL=gpt-4.1-mini
    AGENTLY_NEWS_API_KEY=your_api_key
    
    • Adjust language / search / concurrency settings if needed
    • If your OpenAI-compatible endpoint does not require authentication, you can leave AGENTLY_NEWS_API_KEY unset and the project will skip auth.
    1. Run:
    python app.py
    

    Or pass a topic directly:

    python app.py "AI agents"
    

    Project Structure

    .
    ├── app.py
    ├── news_collector/
    ├── tools/
    ├── workflow/
    ├── prompts/
    ├── outputs/
    ├── logs/
    └── v3/
    

    Important v3 -> v4 Changes

    The business chain is still roughly:

    outline -> search -> pick -> browse + summarize -> write column -> render markdown

    What changed is the engineering shape around that chain.

    Project-level changes

    • The old v3 project used a main workflow plus a nested column workflow under ./workflows, with custom search.py / browse.py helpers and storage-style state passing.
    • The v4 project separates responsibilities more clearly:
      • news_collector/: app/integration layer
      • workflow/: parent flow, column sub flow, and concrete chunk logic
      • tools/: search/browse adapter layer
      • prompts/: structured prompt contracts
    • Model configuration is no longer hardcoded in Python. It now uses ${ENV.xxx} placeholders from SETTINGS.yaml, so deployment and local switching are simpler.
    • 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.
    • The workflow plan is now closer to the business boundary:
      • parent flow: prepare_request -> generate_outline -> for_each(column) -> render_report
      • column sub flow: search -> pick -> summarize -> write_column
      • 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
      • this keeps the parent focused on report orchestration and the child focused on one column lifecycle
      • 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

    Agently v4 features used here

    • TriggerFlow orchestration
      • Replaces the old v3 workflow style with a more explicit flow graph (to, for_each, sub flow, branching-ready composition).
      • Unlike the old v3 Workflow chain, TriggerFlow here runs columns concurrently and also summarizes picked stories concurrently within each column.
      • 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/child flows instead of one oversized chunk.
    • Sub flow composition
      • 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).
      • Meaning for this project:
        • the parent flow stays focused on report-level orchestration
        • the column pipeline can be tested, visualized, and exported independently
        • 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
        • capture / write_back makes the boundary between parent and child explicit for input, state, and resources
    • Structured output contracts
      • YAML prompts now define output schema directly for outline generation, news picking, summarizing, and column writing.
      • Meaning for this project: much less handwritten parsing glue, clearer interfaces between steps, and easier prompt iteration.
    • Built-in Search / Browse tools
      • The project now defaults to Agently v4 built-in tool implementations instead of the old project-local helpers.
      • Meaning for this project: less custom infrastructure code, and users can still swap implementations through ./tools without rewriting the workflow.
    • Runtime resources and state namespaces
      • TriggerFlow runtime resources are used to inject logger/search/browse dependencies, while runtime state stores execution data such as request, outline, and intermediate results.
      • Meaning for this project: dependency wiring and execution state are separated cleanly, which keeps chunk code thinner and more maintainable.
    • Environment-aware settings
      • Agently v4 set_settings(..., auto_load_env=True) works directly with ${ENV.xxx} placeholders.
      • Meaning for this project: model endpoint, model name, and API key can be switched by environment instead of editing code or committing secrets.

    Overall effect on this project

    • The core product behavior remains familiar to v3 users, but the project now has a cleaner app/workflow/tools/prompts split.
    • More logic is expressed in Agently-native capabilities instead of project-specific glue code.
    • 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.
    • 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.
    • 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.

    Notes

    • Python >=3.10 is required because Agently v4 requires it.
    • This project requires Agently >=4.0.8.3.
    • Model settings now use Agently v4 auto_load_env=True with ${ENV.xxx} placeholders.
    • tools/ defaults to Agently v4 built-in implementations, but you can replace the factories there with your own tools.
    • workflow/ is now split by business boundary into the parent flow, the column sub flow, report-level chunks, and column-level chunks.
    • news_collector/ acts as the app/integration layer for configuration, model wiring, and CLI entry support.
    • The current sample SETTINGS.yaml enables BROWSE.enable_playwright: true by default because many news pages need a real browser to return usable content.
    • 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.
    • 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.