包含关键字 typecho 的文章

作者:濯光

背景与挑战:多智能体协作中的典型问题

随着 AI Agent 技术的快速发展,单一智能体已经难以满足复杂业务场景的需求。多智能体协作(Multi-Agent Collaboration)正在成为 AI 应用的主流趋势——让多个具备不同专长的智能体协同工作,共同完成复杂任务。

Google 于 2025 年初发布的 A2A(Agent-to-Agent)协议,为多智能体间的标准化通信提供了重要基础。A2A 协议定义了智能体之间的发现、能力描述和任务交互标准,使得不同来源、不同框架的智能体能够无缝协作。

image

然而,Dify 平台目前原生并不支持 A2A 协议。这意味着开发者无法直接在 Dify 中发现和调用遵循 A2A 标准的智能体,缺乏与 A2A 生态进行集成的有效途径。具体来说,Dify 开发者面临以下挑战:

  • 协议不兼容: Dify 原生不支持 A2A 协议,无法直接解析 AgentCard、处理 A2A 消息格式,与已有的 A2A Agent 生态完全隔离。
  • 智能体发现困难: 多个 A2A Agent 分散部署在不同环境中,没有标准方式让 Dify 应用发现和管理这些智能体,每次接入都需要大量定制开发。
  • 动态选择受限: 传统方式下,Dify 应用只能调用预先硬编码的单一智能体,无法根据实际任务需求动态选择最合适的智能体。
  • 协作编排复杂: 当业务需要多个智能体协作时,开发者需要在工作流中进行大量的条件判断和路由逻辑,开发和维护成本高。
  • 缺乏统一注册中心: 没有集中管理 A2A Agent 的平台,难以对智能体进行统一的注册、发现和治理。
  • 无法对外暴露: Dify 构建的智能体应用只能在 Dify 平台内使用,无法以标准协议对外提供服务,难以被其他 A2A 生态中的智能体发现和调用。

这些问题导致 Dify 开发者在构建多智能体应用时,面临协议不通、接入成本高、扩展性差、灵活度低、无法对外互通的困境。

解决方案:Nacos Agent Registry + A2A 插件组合

为了解决上述问题,Nacos 官方为 Dify 平台打造了双向 A2A 协议集成方案,通过两个互补的插件填补了 Dify 在 A2A 协议支持上的空白,让 Dify 应用既能调用外部 A2A 智能体,又能作为 A2A 智能体被外部系统调用。

Nacos 3.0 在支持 MCP Registry 的基础上,进一步拓展了对 A2A Agent 的支持能力,推出了 Nacos Agent Registry——一个统一的 AI 智能体注册与发现平台。结合 A2A 插件组合,Dify 开发者可以:

A2A Discovery 插件(调用外部智能体)

  • 打通 A2A 协议: 插件内置完整的 A2A 协议支持,自动解析 AgentCard、处理标准消息格式,让 Dify 与 A2A 生态无缝对接。
  • 统一智能体发现: 自动从 Nacos Agent Registry 发现所有已注册的 A2A Agent,无需手动配置每个智能体的连接信息。
  • 动态智能体选择: LLM 可以根据任务需求,从多个可用智能体中智能选择最合适的一个进行调用。
  • 灵活的发现模式: 支持 Nacos 模式和 URL 模式两种发现方式,满足不同部署场景的需求。

A2A Server 插件(暴露 Dify 应用)

  • 标准协议暴露: 将 Dify 中的任意应用(Chatbot/Agent/Chatflow/Workflow)暴露为符合 A2A 协议标准的智能体。
  • 自动注册发现: 支持将 Dify 应用自动注册到 Nacos Agent Registry,让其他智能体能够发现和调用。
  • 多轮对话支持: 基于 Dify Plugin Storage 维护会话上下文,支持跨请求的连续对话。
  • 标准端点: 提供标准的 /.well-known/agent.json 端点用于智能体元数据发现。

目前,Nacos 官方 A2A 插件已正式上架 Dify 官方插件市场:

整体架构

image

核心功能详解

3.1 A2A Discovery 插件:调用外部智能体

3.1.1 两种智能体发现模式

Nacos 模式(推荐)

通过 Nacos Agent Registry 统一管理和发现智能体。只需在 Nacos 中注册 A2A Agent,Dify 应用即可自动发现并调用。

优势:

  • 集中化管理,智能体信息统一维护。
  • 支持动态注册和注销,无需重启 Dify 应用。
  • 与 Nacos 生态无缝集成,享受企业级治理能力。

配置示例:

discovery_type: nacos
available_agent_names: translator_agent,search_agent,code_agent
namespace_id: public

URL 模式

直接通过 A2A Agent 的标准 URL 进行发现,适合无需 Nacos 的轻量级场景。

配置示例:

discovery_type: url
available_agent_urls: {
  "translator_agent": "http://host1:8080/.well-known/agent.json",
  "search_agent": "http://host2:8080/.well-known/agent.json"
}

3.1.2 两个核心工具

获取智能体信息(get_a2a_agent_information)

查询所有配置的 A2A Agent 的详细信息,包括:

  • 智能体名称(agent_name)
  • 功能描述(description)
  • 技能列表(skills)

LLM 通过这些信息了解每个智能体的能力,为后续的智能选择提供依据。

调用智能体(call_a2a_agent)

根据 LLM 的选择,向指定的 A2A Agent 发送查询消息并获取响应。支持:

  • 动态选择目标智能体
  • 自定义查询消息
  • 完整的上下文传递

3.1.3 智能体动态选择工作流

image

通过以上两种工具协同配合,Dify 中的 Agent 可以实现:

  1. 全面了解可用的智能体资源
  2. 根据具体任务智能匹配最佳智能体
  3. 实现真正的多智能体动态协作

3.2 A2A Server 插件:暴露 Dify 应用

A2A Server 插件让 Dify 应用能够以标准 A2A 协议对外提供服务,使其他智能体能够发现和调用。

3.2.1 支持的应用类型

A2A Server 支持将以下类型的 Dify 应用暴露为 A2A 智能体:

image

3.2.2 两个核心端点

智能体元数据端点(GET /.well-known/agent.json)

返回符合 A2A 协议的 AgentCard,包含:

  • 智能体名称(name)
  • 功能描述(description)
  • 访问地址(url)
  • 版本信息(version)
  • 能力声明(capabilities)
  • 技能列表(skills)

外部调用方通过此端点发现智能体的能力和调用方式。

JSON-RPC 调用端点(POST /a2a)

处理 A2A 协议标准的 JSON-RPC 请求。支持:

  • message/send 方法:向智能体发送消息并获取响应
  • 多轮对话上下文维护
  • 完整的任务状态管理

3.2.3 Nacos 自动注册

启用 Nacos 注册后,A2A Server 会在首次收到 AgentCard 请求时自动将 Dify 应用注册到 Nacos Agent Registry。注册后,其他 A2A 智能体可以通过 Nacos 发现并调用该 Dify 应用。

3.2.4 多轮对话支持

A2A Server 基于 Dify Plugin Storage 实现跨请求的会话上下文管理:

  • 自动维护 conversation_id 映射
  • 支持连续多轮对话
  • 会话状态持久化存储

实践教程:构建多智能体协作应用

本章将通过两个具体案例,分别演示 A2A Discovery 和 A2A Server 插件的使用方法。

4.1 使用 A2A Discovery 调用外部智能体

让我们通过一个具体案例,演示如何使用 A2A Discovery 插件构建一个多智能体协作的 AI 助手。

image

场景描述

假设我们要构建一个智能客服系统,需要调用以下三个专业智能体:

  • 翻译智能体: 处理多语言翻译需求
  • 搜索智能体: 查询产品信息和知识库
  • 客服智能体: 处理订单查询和售后问题

步骤一:在 Nacos 注册 A2A Agent

将 A2A Agent 注册到 Nacos Agent Registry 有两种方式:

方式一:控制台手动注册

  1. 登录 MSE Nacos 控制台2. 进入「智能体注册中心」3. 添加各个 A2A Agent 的信息(名称、访问地址、描述等)

方式二:AgentScope 自动注册(推荐)

AgentScope [ 1] 是阿里巴巴推出的一款以开发者为核心,专注于多智能体开发的开源框架。它的核心目标是解决智能体在构建、运行和管理中的难题,提供一套覆盖“开发、部署、监控”全生命周期的生产级解决方案。

AgentScope 最新版本中,已经全面支持 A2A 协议,并集成 Nacos 作为 A2A Registry 的默认实现,构建了一套从开发到部署的完整分布式多智能体协作体系。使用 AgentScope 构建的 A2A Agent 可以自动注册到 Nacos,无需手动配置。以下为参考代码:

from agentscope_runtime.engine.app import AgentApp
from agentscope_runtime.engine.deployers.adapter.a2a import (
AgentCardWithRuntimeConfig,
)
from agentscope_runtime.engine.deployers.adapter.a2a.nacos_a2a_registry import (
NacosRegistry,
)
from v2.nacos import ClientConfigBuilder
# 创建 Nacos Registry 实例
registry = NacosRegistry(
    nacos_client_config=ClientConfigBuilder()
    .server_address("mse-xxx.nacos.mse.aliyuncs.com:8848")
    # 其他可选配置项
    .build()
)
app = AgentApp(
    app_name="translator_agent",
    app_description="TestAgent",
    # 在 a2a_config 中配置 registry
    a2a_config=AgentCardWithRuntimeConfig(registry=registry),
)

更多集成方式请参考 AgentScope 官方文档 [ 2]

步骤二:安装配置 A2A Discovery 插件

  1. 在 Dify 插件市场搜索「A2A Agent Client」或直接访问插件页面 [ 3]
  2. 点击安装插件
  3. 配置 Nacos 连接信息:

image

步骤三:创建 Dify Agent 应用

  1. 在 Dify 中创建一个新的 Agent 应用
  2. 添加 A2A Discovery 插件的两个工具:

    • get_a2a_agent_information
    • call_a2a_agent
  3. 配置工具参数:
discovery_type: nacos
available_agent_names: translator_agent,search_agent,customer_service_agent
namespace_id: public
  1. 设置系统提示词:
你是一个智能客服助手,可以调用多个专业智能体来处理用户请求。
工作流程:
1. 首先调用 get_a2a_agent_information 获取所有可用智能体的信息
2. 根据用户的问题类型,选择最合适的智能体
3. 调用 call_a2a_agent 向选中的智能体发送请求
4. 整合响应结果,为用户提供完整的答案
可用的智能体包括翻译、搜索、客服等,请根据任务特点智能选择。

步骤四:测试验证

部署应用后,尝试以下对话:

用户:请帮我把"How to return the product?"翻译成中文

AI 助手(内部流程):

  1. 调用 get_a2a_agent_information 获取智能体列表
  2. 识别这是翻译任务,选择 translator_agent
  3. 调用 call_a2a_agent 发送翻译请求
  4. 返回翻译结果

用户: 我想查询订单 #12345 的物流状态

AI 助手(内部流程):

  1. 识别这是客服问题,选择 customer_service_agent
  2. 调用智能体获取订单信息
  3. 返回物流状态

4.2 使用 A2A Server 暴露 Dify 应用

现在让我们演示如何使用 A2A Server 插件将 Dify 应用暴露为 A2A 智能体,让其他系统能够发现和调用。

场景描述

假设我们已经在 Dify 中构建了一个强大的「智能客服助手」应用,现在希望将其暴露为 A2A 智能体,让:

  • 其他 AgentScope 应用可以调用
  • 其他 A2A 生态中的智能体可以发现并协作
  • 外部 AI 应用可以通过标准协议接入

步骤一:安装 A2A Server 插件

  1. 在 Dify 插件市场搜索「A2A Server」或直接访问插件页面 [ 4] 2. 点击安装插件

步骤二:创建 Endpoint

  1. 进入插件管理页面,找到 A2A Server 插件
  2. 点击「创建 Endpoint」
  3. 配置基本参数:

image

  1. 点击保存,Dify 会生成 Endpoint ID

步骤三:更新正确的 URL

保存后,获取生成的 Endpoint ID(如 abc123),然后:

  1. 返回编辑 Endpoint2. 将 Agent Public URL 更新为正确的地址:
 https://your-domain.com/e/abc123/a2a
  1. 保存配置

最终的 A2A 端点:

  • AgentCard 地址: https://your-domain.com/e/{endpoint_id}/a2a/.well-known/agent.json
  • JSON-RPC 地址: https://your-domain.com/e/{endpoint_id}/a2a

步骤四:配置 Nacos 注册(可选)

如果希望智能体能被自动发现,可以配置 Nacos 注册:

image

步骤五:测试验证

测试 AgentCard 获取

curl https://your-domain.com/e/{endpoint_id}/a2a/.well-known/agent.json

成功返回示例:

{
  "name": "smart-service-agent",
  "description": "智能客服助手,支持订单查询、售后服务、产品咨询",
  "url": "https://your-domain.com/e/abc123/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": false,
    "push_notifications": false
  },
  "skills": [
    {
      "id": "dify_app",
      "name": "smart-service-agent",
      "description": "智能客服助手,支持订单查询、售后服务、产品咨询"
    }
  ]
}

测试消息发送

使用 A2A SDK 或兼容客户端发送消息:

from a2a.client import A2AClient
client = A2AClient("https://your-domain.com/e/{endpoint_id}/a2a")
response = client.send_message("我想查询订单 #12345 的状态")
print(response.text)

与 AgentScope 集成

AgentScope 配置完成后,AgentScope 应用可以通过 Nacos 自动发现并调用该 Dify 智能体:

from agentscope.agent import A2AAgent
from agentscope.a2a import NacosAgentCardResolver
from agentscope.message import Msg
# Python AgentScope v1.0.11以上
# 创建 Nacos AgentCard Resolver
nacos_resolver = NacosAgentCardResolver(
    remote_agent_name="my-remote-agent",  # Nacos 中注册的智能体名称
    nacos_client_config=ClientConfig(
        server_addresses="http://localhost:8848",  # Nacos 服务器地址
        # 其他可选配置项
    ),
)
# 使用 Resolver 创建 A2AAgent,通过名称从 Nacos 发现 Agent
agent = A2AAgent(
    agent_card=await nacos_resolver.get_agent_card()
)

更多集成方式请参考 AgentScope 官方文档。

Nacos Agent Registry 企业级能力

image

统一注册发现

所有 A2A Agent 集中注册到 Nacos,开发者无需关心智能体的具体部署位置。新增智能体时只需注册到 Nacos,Dify 应用即可自动发现并调用,支持动态上下线。

多租户隔离

基于 Nacos 的命名空间隔离机制,可以将不同环境(开发、测试、生产)或不同业务线的智能体完全隔离,互不影响,满足企业级多租户场景。

健康检查

Nacos 自动监控各智能体的运行状态,当某个 Agent 不可用时自动从服务列表中摘除,避免调用失败,恢复后自动重新上线。

元信息管理

支持在运行时动态更新智能体的描述、技能列表等元信息,无需重启服务。这对于智能体能力迭代升级非常友好。

访问控制

通过 Nacos 的认证鉴权机制,可以精细控制哪些应用可以访问哪些智能体,保障企业级应用的安全性。

生态集成

Nacos Agent Registry 不仅支持 A2A 协议,还与阿里云 AI 网关、AgentScope 等组件无缝对接,构建完整的智能体治理生态。

image

总结与展望

A2A 插件组合填补了 Dify 平台在 A2A 协议支持上的空白,为 Dify 开发者带来了双向多智能体协作能力:

  • 双向协议支持: A2A Discovery 调用外部智能体,A2A Server 暴露 Dify 应用,实现完整的 A2A 生态互通。
  • 简化接入: 通过 Nacos Agent Registry,一次配置即可发现所有智能体,也可让 Dify 应用被自动发现。
  • 智能选择: LLM 根据任务需求动态选择最合适的智能体。
  • 标准协议: 完全遵循 Google A2A 协议,与各类实现无缝兼容。
  • 生态互通: 与 AgentScope 等主流智能体框架深度集成,Dify 应用可被其他 AI 平台发现和调用。
  • 企业级治理: 依托 Nacos 平台,享受完整的智能体管理能力。

随着 AI 多智能体技术的持续演进,Nacos 将继续深耕 AI Agent 生态,从 MCP Server 管理到 A2A Agent 协作,与 AgentScope 等主流智能体框架深度集成,为开发者提供更加完善的智能体治理平台。通过 A2A Discovery 和 A2A Server 插件的组合,Dify 开发者现在可以构建真正开放互联的智能体应用——既能调用生态中的各类专业智能体,也能将自己的智能体能力开放给整个 A2A 生态。未来,我们还将支持更多的智能体协议和更丰富的治理能力,助力开发者构建更加强大的 AI 应用。

相关链接:

[1] AgentScope

https://github.com/modelscope/agentscope

[2] AgentScope 官方文档

https://github.com/modelscope/agentscope

[3] 插件页面

https://marketplace.dify.ai/plugins/nacos/a2a_discovery?langu...

[4] 插件页面

https://marketplace.dify.ai/plugins/nacos/a2a_server?language...

参考链接:

[1] A2A 插件源代码(GitHub)

https://github.com/nacos-group/nacos-dify-plugins

[2] Nacos 官网

https://nacos.io/

[3] Nacos GitHub 仓库

https://github.com/alibaba/nacos

[4] Google A2A 协议

https://github.com/google/A2A

[5] Dify 官网

https://dify.ai/

[6] Nacos MCP 插件

https://marketplace.dify.ai/plugins/nacos/nacos_mcp?language=...

本文集中测评了 10 款需求管理工具:ONES、Tower、Jira、Azure DevOps、YouTrack、Productboard、Aha! Roadmaps、Jama Connect、IBM DOORS Next、Siemens Polarion ALM,用同一条“需求生命周期”做对比,给你一份新人也能直接参考的选型与避坑清单。

30秒速读

  • 你想先把“需求入口统一、推进可见”跑起来:优先看 ONES / Tower / YouTrack
  • 你要把“需求—任务—测试—缺陷”串成闭环:优先看 ONES / Jira / Azure DevOps Boards
  • 你做的是高风险/强合规/返工成本极高的项目:优先看 Jama / IBM DOORS Next / Polarion

需求管理工具到底管什么

很多新人会把需求管理工具理解成“写 PRD 的地方”。但我实际用下来,真正能减少返工的,是它帮你把需求跑通这 5 件事:

  1. 需求入口(收集):把分散渠道的想法收拢到同一处(需求池/Backlog)
  2. 共识形成(澄清/评审):讨论不只是聊天,要能沉淀“结论、决策人、待办问题”
  3. 优先级与排期(排序/路线图):把“想要”变成“什么时候做、为什么先做”
  4. 交付关联(拆解/追踪):需求要能关联任务、测试、缺陷、发布版本,避免断链
  5. 变更控制(影响分析/追溯):变更要可追踪、可回看,最好能提示影响范围(谁会被波及)

你会发现:当团队说“我们缺需求管理”,真正缺的往往是第4和第5——需求和交付没串起来、变更没被控制住。

新 PM 选需求管理工具:4个标准 + 一张评分表(复制即用)

先说我现在非常认同的结论:找到适合自己团队节奏的工具,比追热门更重要。

1)四个标准:决定你能不能真正用起来

  • 易用性:新人能否 1 小时内完成“建需求—@负责人—改状态—看进度”。
  • 上手门槛:是不是一上来就要配置一堆字段、工作流、权限?(很多团队死在“配置过度”)
  • 协作体验:跨岗位参与是否顺滑(评论、通知、权限、结论沉淀)。
  • 学习曲线:能否“先最小闭环跑起来”,再逐步加规则与追溯。

2)两道判断题:帮你决定要不要上工具

  • 你们每周变更≥2次,还经常牵一发动全身?→ 你需要更强的变更影响分析/追溯(需求关联任务/测试/缺陷)。
  • 你们要对外承诺版本、交付窗口,事后要复盘证据?→ 你需要更强的基线/审计友好能力。

3)选型评分表

给你一个我自己用的快速打分表——每项 0/1/2 分,总分越高越适合当前阶段:

  • 需求入口是否统一(需求池/Backlog/表单)
  • 评审是否能沉淀决策(结论/待办问题/责任人)
  • 优先级与版本规划是否顺手(排序/路线图/迭代)
  • 需求是否能关联交付(任务/测试/缺陷/发布)
  • 变更是否可控(影响范围/追溯/基线)
  • 团队是否愿意天天打开(易用性/通知/体验)

项目需求管理工具盘点与测评(10款)

我用同一条“需求链路”去试每个工具:收集 → 澄清/评审 → 排序 → 拆解 → 交付关联 → 变更控制 → 验收回看。下面每款我都按同一套结构写,方便你直接对比。

1)ONES:把“需求—任务—测试”闭环跑顺

ONES 是一套能把需求管理、项目执行与质量追踪串起来的底座型需求管理工具,适合帮助研发团队打造“需求从收集到交付”的闭环。

整体来看,ONES 可以满足前面所提到的需求管理 5 项能力:入口(需求池/未规划)+ 排序(迭代规划)+ 交付关联(需求跟踪/测试关联)。我用 ONES 做项目需求管理时,会先把来自业务、市场、客户、测试等渠道的需求统一沉淀到需求池里,再通过需求梳理→需求评审→优先级排期→需求分配的节奏把需求真正“管住”。

优势亮点:除了基本的需求管理能力,ONES 的优势亮点还在于其需求跟踪能力,能把需求和任务、缺陷、测试活动形成关联,这样一来,你在复盘时就能很清楚地回答为什么延期、哪里返工、那些变更影响最大的问题。

我实际会怎么用(新PM可参考):

  • 先建一个“统一入口”的需求池(其他渠道一律转录进来)
  • 状态控制在 6 个以内(收集→澄清→评审→已排期→进行中→已验收)
  • 每次变更只记录“三件事”:改了什么/为什么改/影响谁怎么补
  • 迭代结束用需求关联信息做复盘:哪些需求延期、为什么返工、哪里需要提前评审

适用场景:研发协作、多项目并行、跨部门交付等场景。

2)Tower

如果你当前最大的痛点是“需求入口太散、推进不透明”,Tower 更像一款能让团队快速把需求收回来并看得见进展的轻量需求管理工具。我用 Tower 做需求管理,通常从它的“需求管理模板”起步:用模板把客户反馈、内部建议、业务需求统一收集,再按产品模块、平台、版本、类型等维度做分类筛选——这一步解决的是“需求进哪儿”和“怎么找回”。

在优先级与排期上,我会用自定义字段把优先级规则先落地(例如紧急度、影响范围、客户类型),并通过列表统计或筛选把高频需求聚类出来——这比“凭感觉拍脑袋”更稳。你也可以参考 Tower 团队给出的阶段化需求管理示例(从反馈收集到发布的阶段拆分),对新人 PM 很友好。

我实际会怎么用:

  • 用模板建“需求池/Backlog”,所有反馈先别急着做,先统一收
  • 用自定义字段固定四件事:来源、模块、影响范围、紧急程度
  • 评审只做两类结论:进入排期/暂缓&原因(避免无限讨论)

适用场景:中小团队、产品/运营/市场与研发协作团队。

3)Jira

Jira 更像一套“把需求拆成可交付工作项”的工程化需求管理工具,把需求落在工程执行体系里(Epic/Story/Task),适合流程成熟、愿意治理配置的研发团队。其需求管理强项在于需求拆解层级清晰(epic/story)+ 执行跟踪强。Atlassian 对 epics/stories 的说明强调它们用于把目标拆到细节,并在变化中保持结构与灵活。

我实际会怎么用:

  • 用 Epic 管“业务目标/大需求”,Story 管“可交付的小需求”
  • 每个 Story 写清验收点(否则测试会很痛苦)
  • 自动化别一口气开太多,先保证团队愿意更新状态

优势亮点:生态强、可扩展强,但需要治理。

4)Azure DevOps Boards

如果你的团队开发、代码、构建发布都在微软生态里,Azure DevOps Boards 能把需求到验证的链路拉得更紧。它的需求管理强项在于需求可追溯性——把开发过程两个或更多阶段关联并可前后追踪。你可以把需求(工作项)与测试结果关联,形成端到端可追溯视图,用更直观的方式监控质量状态。再往深一点,ADO 还支持把工作项与分支、提交、PR、构建、发布等对象建立关联,从而形成“从需求到上线”的全链路追溯,这对变更影响分析和复盘非常有帮助。

当然,这样的局限就是:如果你的协作并不在微软生态里(比如产品侧工具、外部客户反馈系统另有一套),这时你要么加强集成,要么在产品侧搭配更擅长需求洞察/优先级决策的工具。

5)YouTrack

如果你想要一个比 Jira 更轻、但又能把需求拆解与推进节奏管住的工具,YouTrack 是个比较折中的选择。我体验 YouTrack 时,最明显的感受是它把“需求层级”这件事做得很顺:Scrum 项目模板会直接配置 epics、user stories、tasks 等 issue 类型,并自动创建两块敏捷看板——一块管 epic+story 的大盘视角,一块管 story+task 的执行视角。 对新人 PM 来说,这等于直接给了你一套可运行的“需求→交付”结构,不用先研究一堆概念。

局限性也很明显:YouTrack 更擅长“工程侧需求管理”,在用户反馈洞察、路线图对外表达这类“产品侧语义”上不如专门的产品工具;所以当你的痛点是“先做什么/为什么做”,可能需要搭配 Productboard、Aha! 这类优先级与路线图工具来补齐。

6)Productboard

Productboard 更像一款把用户声音转成优先级与路线图共识的产品型需求管理工具。我用 Productboard 的方式更像在做“需求决策”,而不是盯开发状态:它强调用数据化流程去优先级排序(prioritization),并让利益相关者看到“为什么这么决定”。

我会先把多渠道反馈聚合成可讨论的需求主题(而不是一条条散点),再进入优先级工作流。另外,Productboard 还把常见框架融进去(例如 RICE、drivers、评分模型等),并把“客户重要度、业务价值、投入成本、战略匹配”这类词汇变成可比较的字段与视图,从而把“拍脑袋”变成“有依据的取舍”。

不过需要注意的是,Productboard 更强的是“选什么”,不一定强在“怎么交付”。如果你的团队需要从需求到任务、测试、缺陷的可追溯链,通常要和工程工具(如 ONES/Jira)打通,否则会出现“路线图很清楚,落地进度却在别处”的割裂。

7)Aha! Roadmaps

Aha! Roadmaps 更像把需求放进战略目标与路线图语言里的对齐型需求管理工具。我对 Aha! 的第一印象是:它不是从“任务管理”切入,而是从“战略与路线图”切入。 这意味着它特别适合把需求变成“可沟通的计划”,减少跨部门协作里那种“大家各说各话”的消耗。

Aha 常见用法是把想法/需求先汇总(尤其适合多来源的内部建议和外部反馈),再通过优先级机制把需求沉到 roadmap 上。哪怕你团队暂时不做复杂的评分模型,把需求统一归集、再用一致的标准做取舍,本身就是需求管理成熟度的一大步。它提供 scorecard/优先级视图来帮助团队对齐“价值、成本、风险、战略匹配”等维度,并把这些决策直接映射到路线图表达里(对内对外都更好讲)。

Aha 的局限在于:对新 PM 来说它可能“太战略”,如果你当前的痛点是需求推进与交付跟踪,还是需要配套工程执行工具(ONES/Jira/YouTrack 等)。

8)Jama Connect

Jama Connect 更像一套“以追溯与变更影响为核心”的严肃型需求管理工具。我理解 Jama Connect 的关键词是 Live Traceability(实时追溯):它把需求、测试、关系与协作讨论放在同一套追溯网络里,让你在变更发生前就能评估影响。Jama 的 Review Center 把审查人、批准人、主持人拉到同一个评审上下文里,任何利益相关者都能方便地提供反馈,从而缩短评审周期、减少“邮件/表格来回确认”的损耗。不过,像 Jama Connect 这类工具的学习与实施成本更高,适合“需要的人”。如果你的团队只是轻量产品迭代,可能用不上这么完整的合规/追溯能力。

9)IBM DOORS Next

IBM DOORS Next 更像一本能做基线与追溯的需求账本。它用“链接(links)+追溯(traceability)”把需求和下游对象串起来,让需求不只是文本,而是可以被验证、被审计、被影响分析的结构化对象。DOORS Next 的 baseline set 思路非常典型:当你在不同阶段为模块创建基线时,链接会被维护到基线集中,从而在多个阶段里保持追溯关系不丢失。

DOORS Next 的价值主要体现在“严谨性”和“可证明性”,因此对流程成熟度要求高;如果你的团队只是想解决“需求入口分散、排期不透明”,它会显得过重。

10)Siemens Polarion ALM

Polarion 更像把需求、流程与证据链做成一体化的企业级需求管理平台。Polarion 通过对每条需求的自动变更控制来保证可追溯性,从而通过审计/合规检查;这对高风险行业意味着:你不仅要做对,还要能证明你在正确的流程里做对。Polarion 强调把沟通、追溯、流程内建到平台:支持讨论、通知、告警等协作方式,并配合可配置工作流与权限控制,把“评审/批准/发布”卡口做得更严谨。此外,Polarion 还强调文档复用、分支与变体管理(比如 live branches/document re-use),适合有产品族、多个版本/衍生型号的团队去管理“共性需求与差异需求”。总的来看,Polarion 往往不是“开个账号就能用”的轻量工具,更偏项目化落地。

避坑清单

所谓“需求管理工具落地”,其实就是把这些最小规则落实到工具里,让团队协作不靠记忆力。这是我吃过亏后总结的“最低可运行规则”,你可以直接拿去用:

  1. 入口只保留 1 个:其它渠道可以存在,但必须“转录到主入口”才算有效需求。
  2. 状态不超过 6 个:状态越多,越没人更新。我常用:收集→澄清→评审→已排期→进行中→已验收。
  3. 评审要留下可执行结论:不是记录讨论,而是写清:结论是什么、谁负责、截止是什么。
  4. 变更只记三件事:改了什么、为什么改、影响谁/怎么补。做到这三条,你就已经比多数团队强。
  5. 每两周做一次“需求卫生检查”:过期归档、重复合并、未决拉齐,否则需求池会变成垃圾场。
  6. 验收标准写成“能判对错”的一句话:否则测试会在“我觉得OK”里反复横跳。

转 PM 这段时间,我最大的感悟是:工具不是让项目变复杂的,而是让沟通更简单、节奏更清晰。真正好的需求管理工具,会把“大家脑子里的共识”变成“团队可执行的节奏”,把“临时想起的变更”变成“可控可追溯的决定”。

真这么干可有点牛逼了。。。

据 B 站网友 @GTX690 战术核显卡导弹发布的视频,迅雷下载会检测用户所需文件的文件名然后替换文件,例如用户下载的是 Windows 10 微软官方版镜像文件,会被自动替换为第三方封装的版本。

而第三方封装的版本里默认捆绑预装 360 浏览器、双核浏览器、Win 应用商店、WPS 、夸克、QQ 游戏等,当然也会预装 Chrome 浏览器但已经强制锁定广告版网址导航。

迅雷下载的这种行为已经不能称为替换,毕竟用户输入的下载地址被劫持,这种行为对于使用迅雷下载的用户来说存在极高的威胁,毕竟没人知道迅雷到底会劫持哪些文件,也无法确定第三方提供的版本是否安全。

近期,我们收到少量用户反馈,表示产品中部分功能出现异常。经前端异常日志排查,发现问题集中于页面负责连接 Socket 的脚本文件加载失败。而相关异常日志中的 User-Agent 均包含 baiduboxapp 字样,表明问题均来自百度 App 的访问。

然而,异常日志数量较少,日均仅 100 余条,表明出现概率很低。在测试初期,一台测试手机曾短暂出现同样的现象,但随后多次刷新又恢复正常。过了一段时间,又有另一台手机能复现这个问题,于是抓紧机会进行调试。

排查过程

负责连接 Socket 的脚本文件是通过动态创建 <script> 元素引入的。加载失败不外乎网络异常或脚本执行异常。通过在脚本文件开头增加调试日志,就可以确认该脚本文件是否被正常加载并开始执行。结果符合预期,日志正常地出现在 vConsole 的控制台中。不过有一条 Script error 的异常紧接着日志出现,说明是脚本执行异常

奇怪的是,动态加载脚本时已配置 crossorigin="anonymous" 且服务端已开启跨域支持,理论上应能捕获详细错误信息,但实际却未获取到。为此,我在脚本逻辑外层包裹了 try...catch,最终捕获到具体错误信息:

Cannot read properties of undefined (reading 'nodeType')

并根据行列号定位到以下代码:

addEventListener(terminationEvent, unloadHandler, false);

该代码位于 socket.io-client,它仅仅是调用全局的 addEventListener 函数注册事件回调,与 nodeType 无关。为探究根源,我在该处添加了调试日志:

addEventListener(terminationEvent, unloadHandler, false);
console.log(addEventListener.toString());
console.log(unloadHandler.toString());

最终发现,全局的 addEventListener 方法已被重写,且重写后的实现未处理 this 为 undefined 的情况(即直接调用 addEventListener 而非通过对象调用)。由于在微信、原生浏览器等环境中 addEventListener 均为原生函数,因此推断该重写行为源于百度 App。

随后我又产生了新的疑问:为何多数百度 App 用户访问正常?通过正常设备调试发现,这些设备中的 addEventListener 已经打了补丁——在重写方法中增加了 try...catch 处理。这表明大部分终端已通过热更新应用了该补丁,而少数终端可能因更新失败仍存在该问题

解决方案

针对上述情况,可采取两种解决方案。

方案一是阻止百度 App 重写 addEventListener。在页面加载初期执行以下代码,将 addEventListener 设置为不可写:

if (/\bbaiduboxapp\b/.test(navigator.userAgent)) {
  Object.defineProperty(window, 'addEventListener', {
    value: window.addEventListener,
    writable: false
  });
}

方案二是修改 socket.io-client 的代码,将调用方式由 addEventListener(...) 改为 window.addEventListener(...),确保始终通过 window 对象调用。

方案一实现简单,只需在页面中嵌入上述代码即可;方案二需修改第三方库,维护成本较高。故最终采用方案一,并在发布上线后需持续监控相关异常是否减少。

一、智慧城市中的交通信号挑战

在智慧城市建设中,交通管理是一个关键领域。随着城市规模的扩大,交通流量激增,传统的交通信号控制方法面临巨大的挑战。传统的信号控制系统通常依赖预设的定时模式或简单的流量感应模式,但这些方式未能充分利用实时数据,难以应对不断变化的交通状况。

为了解决这些问题,越来越多的城市开始采用基于数据驱动的智能交通管理系统,尤其是在交通信号控制方面,IP查询的应用为优化交通流提供了重要支撑。

二、IP查询在交通信号控制中的角色

IP查询通过收集和分析大量的IP地址信息,能够为交通管理系统提供有价值的用户位置和流量信息。虽然无法提供高精度的定位和人流量统计数据,也不能实时采集和分析交通流量数据,但它能够辅助交通信号控制系统进行某些方面的数据支持。
image.png
在智慧城市的交通系统中,IP查询可与交通信号控制系统集成,提供以下几种关键应用:

1. 区域交通流量趋势分析:
IP查询工具能够基于IP地址的分布情况,帮助交通管理者分析某些区域的交通流量趋势。例如,某些热门区域的IP流量增多可能意味着该区域的交通状况发生了变化。系统可以提前识别出高流量区域,为信号控制提供参考。

2. 跨时段流量变化分析:
通过历史数据的积累,IP查询工具能够帮助交通管理系统分析不同时间段内流量变化的趋势,从而为信号控制的优化提供依据。通过识别某一时段的交通流量特点,系统可以优化信号周期和绿灯时长。

3. 事件期间的交通流监控:
尽管IP查询工具无法直接识别交通事故或道路封闭等突发事件,但在某些情况下,它可以通过分析用户IP的地理分布情况,间接为交通流量监控提供支持。例如,当某一地区的IP地址出现异常波动时,系统可以根据这些变化调整信号控制策略。

三、传统信号控制方式与IP查询优化后的对比

1. 传统信号控制方式:

传统的交通信号控制方式通常依赖于定时模式或简单的流量检测。定时模式固然可以确保交通流的有序,但无法根据实时交通状况进行调整。而流量检测模式则通过在道路上布设传感器来监测交通流,虽然可以对部分交通问题做出响应,但其数据采集的时效性和准确性依然受限。

例如,在高峰时段,流量检测系统可能未能及时捕捉到某些交通拥堵的信号,导致信号周期无法做出合理调整,造成交通滞留。

2. IP查询优化后的信号控制:

相较于传统方式,利用IP查询优化的交通信号控制系统能够实时采集和分析更为广泛的数据。通过对不同区域的IP地址信息进行分析,交通信号系统能够根据实际的交通流量情况进行更为精准的信号调节。

例如,在某一时间段,系统能够识别出某些区域的交通压力,进而提前调整信号时长,以应对即将到来的高峰流量,提升整体交通流畅度。

四、API集成与数据同步

为了实现IP查询工具与人流量分析系统的顺利集成,以下是主要的技术实现步骤:

1. API接口调用:

将IP查询工具(如IP数据云、IPnews等)提供的API集成到系统中,通过自动化脚本定期发起查询请求,获取目标区域的IP数据。这些IP数据包括地理位置、运营商、ASN号、IP类型等信息,有助于分析目标区域的流量动态。

  • IP数据云应用场景查询API返回值示例

    {
       "code": 200,
       "data": {
       "scenes": {
       "asn": "AS4134",
       "isp": "电信",
       "usage_type": "家庭宽带"
                       }
                   },
    "msg": "success"
    }

2. 数据同步与存储:

将获取的IP查询结果存储到数据库中,与现有的人流量数据进行同步。在数据库中,对比和融合两类数据,以实现更精准的流量分析。

3. 可视化分析:

通过数据分析工具(如Tableau、Power BI、Grafana等)将融合后的数据展示在同一个平台上,便于实时监控与分析。用户可以通过可视化界面,查看区域流量的实时变化,做出快速响应。

五、数据驱动的智能交通信号控制的优势

通过IP查询提供的数据,智能交通信号控制系统能够从多个维度进行分析和调整,实现真正的智能化管理。其主要优势如下:

1. 实时性:

IP查询能够为交通信号系统提供实时的流量数据,帮助系统根据不同区域的流量趋势调整信号灯时长。这使得交通信号控制能够更加灵活应对不断变化的交通状况。

2. 精准性:

基于IP查询提供的数据,交通信号系统能够识别流量变化的规律,进而优化信号配时,避免交通拥堵。

3. 灵活性和可扩展性:

IP查询能够根据不同区域的交通流量变化进行灵活调整,使得交通信号控制系统具备较强的适应性。这意味着,在交通需求变化时,系统能够快速做出调整,减少硬件投入。

六、总结

随着城市交通的智能化进程不断加快,IP查询在交通信号控制系统中的应用为提升交通流畅度和减少拥堵提供了新思路。通过精确的流量数据分析,IP查询工具能够为交通信号系统提供重要支持,帮助城市管理者进行智能决策,最终实现更高效、更安全的交通管理。

近日,OpenAtom openKylin(简称"openKylin")RISC-V SIG(特别兴趣小组)完成一项重要适配验证工作,依托超睿科技UR-DP1000 RISC-V芯片,结合KVM虚拟化技术,成功将开源云计算管理平台OpenStack完整移植至RISC-V架构。此次适配仅完成基础运行验证,实现了Ubuntu、Debian、openKylin等主流Linux发行版的稳定启动与运行,同时可借助DevStack搭建小规模测试环境,后续实际生产能力仍需进一步验证优化,为RISC-V架构在云计算领域的后续探索筑牢基础。

RISC-V云计算生态的待解难题
当前,RISC-V架构在硬件领域的发展速度不断加快,在嵌入式、消费电子等场景的应用逐渐铺开,但在云计算这一关键领域,生态短板始终制约其规模化落地。作为全球主流的开源云管理平台,OpenStack的适配缺失,导致RISC-V架构难以搭建起完整的云基础设施服务体系。此前,RISC-V架构缺乏成熟的虚拟化调度框架与云平台适配方案,开发者无法像在X86或ARM架构上一样,便捷地部署云服务相关能力。同时,硬件与软件层面的适配问题相互交织,让RISC-V云原生应用的开发与部署流程复杂且成本较高,难以在数据中心、边缘云等场景实现广泛应用。超睿科技UR-DP1000芯片的出现,为解决上述难题提供了可靠的硬件支撑。这款RISC-V处理器具备原生虚拟化支持能力,能够为OpenStack的移植与基础运行验证提供稳定且适配的硬件运行环境。

适配验证成果:实现软硬件基础协同运行
openKylin RISC-V SIG团队此次的工作,核心聚焦于硬件适配、虚拟化部署、云平台兼容三大方向,完成了全链路的基础运行验证。1.  KVM虚拟化层与硬件的基础适配运行团队基于超睿科技UR-DP1000芯片的虚拟化特性,完成了KVM/riscv模块的基础适配部署。通过对虚拟化相关机制的调试与优化,打通了芯片硬件与虚拟化层之间的运行链路,确保KVM虚拟化技术能够在该RISC-V芯片上稳定发挥基础作用,为上层云平台的基础运行提供了可靠的虚拟化环境,相关性能与生产适配性仍需进一步测试。2.  OpenStack与主流Linux发行版的基础兼容运行团队顺利完成OpenStack核心组件的RISC-V架构移植工作,解决了移植过程中出现的软件依赖与系统兼容问题,实现了基础功能的正常运行。移植后的OpenStack可兼容Ubuntu 24.04、Debian 13、openKylin 2.0等主流Linux发行版的虚拟机镜像,用户可通过标准OpenStack API开展实例创建、网络配置等基础操作,操作流程与在X86平台上保持一致,同时可借助DevStack快速搭建小规模测试环境,暂未验证其大规模生产场景的承载能力。

未来展望:持续优化,探索生产级适配可能
openKylin RISC-V SIG团队表示,此次OpenStack移植及基础运行验证的完成,只是RISC-V云计算生态探索的起点,目前仅实现基础运行能力,实际生产能力仍有待进一步验证与优化。接下来,团队将与超睿科技、RISC-V国际基金会等合作伙伴深化协作,推进两项重点工作。
1.推进上游社区融合:计划在未来3-6个月内,将RISC-V架构下的OpenStack适配代码、KVM相关优化成果贡献至上游社区,推动OpenStack官方正式支持riscv64架构,同时参与RISC-V虚拟化技术标准的制定,减少生态碎片化问题,为后续生产级适配奠定基础。
2.开展生产级适配测试:针对边缘云、工业云等特色场景,逐步开展基于超睿UR-DP1000芯片、OpenStack与KVM技术的生产级适配测试,完善资源调度策略,验证平台的规模化部署能力与安全隔离水平,逐步推进场景化解决方案的落地探索。
团队的最终目标是,联合各方合作伙伴,逐步完善RISC-V架构下的云计算生态,持续验证并提升相关技术的生产适配能力,让全球RISC-V用户能够便捷地探索云计算服务的应用可能,推动RISC-V架构从小众技术领域,逐步走向主流基础设施行列,为全球开源云生态的发展注入新动力。

立即体验:RISC-V OpenStack基础运行测试指南
为方便全球RISC-V开发者共同参与探索与优化,openKylin社区已开放移植后的OpenStack源码与部署脚本,供开发者开展基础运行测试,相关生产级应用请谨慎使用。开发者可按照以下步骤快速体验:
1.环境准备:准备搭载超睿UR-DP1000芯片的硬件平台,并安装openKylin 2.0 RISC-V版本操作系统。
2.下载部署脚本git clone https://gitee.com/openkylin/devstack.git
3.一键部署cd devstack#部署前请务必查看README./stack.sh
4.测试验证:部署完成后,通过浏览器访问OpenStack Dashboard,即可开展基础的虚拟机实例创建和管理测试。

关于OpenStack和Devstack
OpenStack:是一个庞大的开源软件集合(由 Nova, Neutron, Cinder 等几十个项目组成),用于管理数据中心的所有资源(计算、存储和网络)。
DevStack:实际上是一套脚本(Shell Scripts),它的唯一目的就是从源代码快速克隆并安装一个“最小化”的 OpenStack 环境。

关于openKylin RISC-V SIG
openKylin RISC-V SIG专注于RISC-V架构的开源软件生态建设,工作范围涵盖操作系统移植、工具链开发、云平台适配等核心领域,致力于联合全球开发者共同探索RISC-V技术的应用可能。社区欢迎全球范围内的RISC-V开发者、硬件厂商、科研机构加入,共同推动RISC-V技术的创新与落地。
SIG主页:https://gitee.com/openkylin/community/tree/master/sig/RISC-V

还有一些细节正在处理, 支持输入 github 仓库地址来检索目录下的 markdown 文件并展示, 做了连续加载和加入书架的一些操作简化

如果以后 V 友在这节点发布连载小说, 就可以 at 我, 或者我提供一个工具, 让一个自动化工具扫描 V 友提供的小说名, 然后根据规则拆分帖子, 导出一个 markdown 文件到 github 仓库中, 每一本小说都是一个文件夹.

这样其他 V 友就可以通过我做的这个工具来阅读在这个节点下发布的所有上架的小说了, 解决了帖子太分散, 不能连贯阅读的缺憾

等我优化完细节, 试用一段时间之后, 会开源这个小作品.

另附一个因为这个阅读器延伸出来的小项目截图, 打算用这个渡过前期这个节点的小说资源太少的尴尬时期:

ps: AI 生成小说实在是太耗 token 了

🌟 TrendForge 每日精选 - 发现最具潜力的开源项目
📊 今日共收录 12 个热门项目,涵盖 50 种编程语言

🌐 智能中文翻译版 - 项目描述已自动翻译,便于理解

🏆 今日最热项目 Top 10

🥇 thedotmack/claude-mem

项目简介: Claude Code插件可自动记录编码会话中Claude的全部操作,通过AI技术进行压缩处理,并将相关上下文智能注入后...

今日新增: 2638 | 总星数: 22452 | 语言: TypeScript

项目截图:

thedotmack/claude-mem

https://github.com/thedotmack/claude-mem


🥈 openai/skills

项目简介: Codex 技能目录

今日新增: 746 | 总星数: 3646 | 语言: Python

https://github.com/openai/skills


🥉 OpenBMB/ChatDev

项目简介: ChatDev 2.0:基于大语言模型的多智能体协作实现全流程开发

今日新增: 227 | 总星数: 29961 | 语言: Python

项目截图:

OpenBMB/ChatDev

https://github.com/OpenBMB/ChatDev


4. pedramamini/Maestro

项目简介: 智能体编排指挥中心

今日新增: 187 | 总星数: 1650 | 语言: TypeScript

项目截图:

pedramamini/Maestro

https://github.com/pedramamini/Maestro


5. Canner/WrenAI

项目简介: ⚡️ GenBI(生成式商业智能)支持使用自然语言查询任意数据库,可在数秒内生成精准的SQL(文本转SQL)、图表(文本...

今日新增: 89 | 总星数: 13897 | 语言: TypeScript

项目截图:

Canner/WrenAI

https://github.com/Canner/WrenAI


6. microsoft/qlib

项目简介: Qlib是一款面向AI的量化投资平台,其目标是从创意探索到生产部署的全流程,通过人工智能技术赋能量化研究。该平台支持多种...

今日新增: 83 | 总星数: 36521 | 语言: Python

项目截图:

microsoft/qlib

https://github.com/microsoft/qlib


7. LadybirdBrowser/ladybird

项目简介: 真正独立的网页浏览器

今日新增: 68 | 总星数: 58263 | 语言: C++

https://github.com/LadybirdBrowser/ladybird


8. disler/claude-code-hooks-mastery

项目简介: 主Claude代码钩子

今日新增: 47 | 总星数: 2351 | 语言: Python

项目截图:

disler/claude-code-hooks-mastery

https://github.com/disler/claude-code-hooks-mastery


9. nvm-sh/nvm

项目简介: Node 版本管理器 - 符合 POSIX 标准的 bash 脚本,用于管理多个活跃的 node.js 版本

今日新增: 35 | 总星数: 91244 | 语言: Shell

https://github.com/nvm-sh/nvm


10. likec4/likec4

项目简介: 通过代码生成的实时动态图表,实现软件架构的可视化、协作与持续演进。

今日新增: 29 | 总星数: 1421 | 语言: TypeScript

项目截图:

likec4/likec4

https://github.com/likec4/likec4


🌈 分语言热门项目

● C++ 最热项目

项目名称: LadybirdBrowser/ladybird

项目描述: 真正独立的网页浏览器

今日新增: 68 | 总数: 58263

地址: https://github.com/LadybirdBrowser/ladybird


项目名称: dail8859/NotepadNext

项目描述: Notepad++ 的跨平台重实现版本

今日新增: 37 | 总数: 13347

项目截图:

dail8859/NotepadNext

地址: https://github.com/dail8859/NotepadNext


项目名称: deskflow/deskflow

项目描述: 在多个计算机之间共享同一套键盘和鼠标。

今日新增: 34 | 总数: 23680

项目截图:

deskflow/deskflow

地址: https://github.com/deskflow/deskflow


● PowerShell 最热项目

项目名称: ScoopInstaller/Scoop

项目描述: Windows 命令行安装程序

今日新增: 10 | 总数: 23568

地址: https://github.com/ScoopInstaller/Scoop


项目名称: microsoft/Agents

项目描述: Microsoft 365 Agent SDK 简化了为 M365、Teams、Copilot St...

今日新增: 7 | 总数: 705

地址: https://github.com/microsoft/Agents


项目名称: microsoft/fabric-toolbox

项目描述: Fabric工具箱是由Fabric CAT提供的工具、加速器、脚本和示例存储库,旨在加速您在Micr...

今日新增: 5 | 总数: 659

地址: https://github.com/microsoft/fabric-toolbox


● Vue 最热项目

项目名称: dreamhunter2333/cloudflare_temp_email

项目描述: CloudFlare 免费临时域名邮箱 支持附件收发 IMAP SMTP TelegramBot

今日新增: 40 | 总数: 5930

项目截图:

dreamhunter2333/cloudflare_temp_email

地址: https://github.com/dreamhunter2333/cloudflare_temp_email


项目名称: CorentinTh/it-tools

项目描述: 专为开发者打造的便捷在线工具集合,拥有卓越的用户体验。

今日新增: 21 | 总数: 36877

项目截图:

CorentinTh/it-tools

地址: https://github.com/CorentinTh/it-tools


项目名称: Lissy93/dashy

项目描述: 🚀 可自托管的个人仪表板,包含状态检查、小组件、主题、图标包、UI编辑器及更多功能!

今日新增: 17 | 总数: 23901

项目截图:

Lissy93/dashy

地址: https://github.com/Lissy93/dashy


● Vim Script 最热项目

项目名称: junegunn/vim-plug

项目描述: 🌺 极简Vim插件管理器

今日新增: 5 | 总数: 35532

项目截图:

junegunn/vim-plug

地址: https://github.com/junegunn/vim-plug


项目名称: tpope/vim-fugitive

项目描述: fugitive.vim:一个强大到堪称非法的 Git 封装工具

今日新增: 4 | 总数: 21626

地址: https://github.com/tpope/vim-fugitive


项目名称: ggml-org/llama.vim

项目描述: LLM辅助代码/文本补全的Vim插件

今日新增: 1 | 总数: 1856

项目截图:

ggml-org/llama.vim

地址: https://github.com/ggml-org/llama.vim


● Shell 最热项目

项目名称: obra/superpowers

项目描述: Claude Code 超级能力:核心技能库

今日新增: 993 | 总数: 44435

地址: https://github.com/obra/superpowers


项目名称: automazeio/ccpm

项目描述: 基于GitHub Issues与Git工作树实现并行智能体执行的Claude Code项目管理系统。

今日新增: 387 | 总数: 6982

项目截图:

automazeio/ccpm

地址: https://github.com/automazeio/ccpm


项目名称: anthropics/claude-code

项目描述: Claude Code是一款基于终端的智能编程工具,它能理解您的代码库并通过自然语言命令执行常规任务...

今日新增: 351 | 总数: 64053

项目截图:

anthropics/claude-code

地址: https://github.com/anthropics/claude-code


● PHP 最热项目

项目名称: coollabsio/coolify

项目描述: 开源且可自行托管的Heroku/Netlify/Vercel替代方案。

今日新增: 34 | 总数: 50269

项目截图:

coollabsio/coolify

地址: https://github.com/coollabsio/coolify


项目名称: filamentphp/filament

项目描述: Laravel强大的开源UI框架 • 借助Livewire快速构建与部署管理后台及应用系统

今日新增: 27 | 总数: 29055

项目截图:

filamentphp/filament

地址: https://github.com/filamentphp/filament


项目名称: krayin/laravel-crm

项目描述: 面向中小企业和企业的免费开源 Laravel CRM 解决方案,提供完整的客户生命周期管理。

今日新增: 24 | 总数: 21104

项目截图:

krayin/laravel-crm

地址: https://github.com/krayin/laravel-crm


📈 今日趋势分析

最活跃语言: TypeScript(4个)、Python(4个)、C++(1个)

今日总获星: 4,180 颗星

平均获星: 348 颗星/项目

今日之星: thedotmack/claude-mem (2638)


📊 数据总览

指标数值
收录项目12
编程语言50
今日新增4,180 颗星
报告日期2026年02月04日
统计周期日报

TrendForge 致力于追踪全球开源项目动态,每日为开发者精选最具价值的 GitHub 项目。

数据来源: https://trendforge.devlive.top/

数据说明: 基于 GitHub 官方 API 数据统计,每日更新

翻译声明: 项目描述采用 AI 智能翻译,如有疏漏请以原文为准

报告生成于: 2026年02月05日

GitHub #开源项目 #技术趋势 #程序员 #软件开发

“我们坚信,开源是推动产品持续演进的关键引擎。尤其在探索 AI 原生场景的过程中,唯有与上下游生态和开发者并肩协作、共创共进,才能走得更远。” 1 月 31 日,在上海举办的 2026 OceanBase 社区嘉年华现场,OceanBase CTO 杨传辉表示。

社区嘉年华是 OceanBase 持续举办的年度品牌活动,至今已有三年,旨在构建开放共享的技术交流平台,链接全球开发者与行业伙伴。

本次活动吸引了 260 余位技术爱好者、开发者参与,通过主题演讲、圆桌对话、AI Coding 实战、社区开放麦等形式,呈现了 10 多场高质量分享,全面展现社区生态活力与技术创新。

开源 4 年累计下载破 10 万次

OceanBase 是一款 100% 自主研发的原生分布式数据库,长期坚持“应用驱动技术创新”的理念,并于 2021 年 6 月正式宣布开源。

OceanBase CTO 杨传辉指出:“底层软件是靠用出来的。谁来用?答案自然是开发者。”他强调,数据库作为数字基础设施,其发展必须与用户和生态共同成长。

OceanBase CTO 杨传辉

他公布了一组数据:自开源以来,OceanBase 全球累计下载量已突破 10 万次,部署节点规模达到数百万级别,并吸引了超过 1600 名外部贡献者参与到代码提交、文档完善及问题修复等共建工作中。

杨传辉表示,开发者是技术落地的重要推动力,也是构建创新生态的基石。这也是 OceanBase 在 2025 年开源首款 AI 原生混合搜索数据库 OceanBase seekdb 的原因。OceanBase seekdb 主打“开箱即用”,开发者仅需三行代码,即可快速构建知识库、智能体等 AI 应用,轻松应对百亿级多模数据检索。“我们目前仍处于探索阶段,期待更多年轻开发者加入,共同推进 AI 与数据库技术的融合。”

开源开放,生态共赢

“社区的每一次进步,都离不开开发者和共建者的支持。”OceanBase 开源生态负责人封仲淹表示。现场,他以“一路有你,OceanBase 社区嘉年华”为主题,分享了 OceanBase 的开源理念与未来规划。

OceanBase 开源生态负责人封仲淹

封仲淹提到,OceanBase 开源已步入第四年,“开源开放,生态共赢”不是一句简单的口号,而是长期坚持的理念。过去一年,在社区开发者的积极参与与生态伙伴的协同推动下,OceanBase 社区版已逐步构建起完善的企业级数据库能力。

截至目前,OceanBase 已联合 400 余家独立软件开发商,共同打造超过 1000 项联合解决方案,拥有 300 多家经销商伙伴及 30 余家交付合作伙伴,累计完成技术集成 1600 余项,持续赋能千行百业的数字化转型。

展望 2026 年,封仲淹表示,OceanBase 将继续深化与生态伙伴的合作,汇聚更多行业力量。一方面积极拥抱 AI 技术,持续建设开发者生态;另一方面坚定推进全球化战略,携手生态上下游伙伴,拓展更多应用场景,助力 OceanBase 走向更广阔的全球市场。

活动当天,OceanBase 还正式聘任 LangChain Ambassador 张海立、Xenera LLM Project Lead 伊洪、英伟达技术专家程治玮、武汉大学国家网络安全学院学生李子毅,以及上海爱可生信息技术股份有限公司的何文超为 OceanBase 年度社区大使。封仲淹表示,期待在全球化道路上与更多社区大使携手同行。同时,2025 OceanBase 社区年度 31 位版主也同步揭晓。

生态共聚:嘉宾共话 AI 数据底座建设

在 AI 时代,构建坚实的数据底座离不开广大开发者的共同参与和生态协作。本次活动邀请了来自不同技术社区的嘉宾,他们结合自身实践与行业思考,围绕 AI 数据底座的构建路径展开深度分享。OceanBase seekdb 作为 AI 原生混合搜索数据库,成为多位嘉宾演讲中的高频词汇。

RAGFlow CEO 张颖峰亲历了从传统搜索到 AI 时代的跨越。“从 RAG 到 Context Engine,构建 AI Agent 的数据基座”为题,进行了分享。

RAGFlow CEO 张颖峰

“在很多人看来,RAG 或许已是过时的技术,但我认为,他恰恰能够成为 AI 原生数据库所需的重要基础。”张颖峰指出,未来的 AI 原生数据库不应仅仅是模型的堆叠,而应以“强检索能力”为核心,构建能够统一管理知识、数据与工具的上下文引擎架构。在这一框架下,单一的 RAG 技术虽已难以应对复杂的交互场景,但可以演进为支持智能体(Agent)的统一上下文引擎,通过“检索前置+上下文优化”机制,实现对结构化与非结构化数据、以及交互记忆(Memory)的综合处理。

他强调,RAG 的本质在于检索。未来的上下文引擎应具备按需为智能体提供精准信息的能力,并借助 OceanBase seekdb AI 原生数据库,支持多模态、高频率的混合检索,最终推动技术实现从单一检索到全方位上下文服务的跨越。

Dify 开源生态负责人郑立

Dify 开源生态负责人郑立以“Dify x OceanBase seekdb”为主题,进行了分享。他通过具体实践案例,介绍了 Dify 的核心能力,以及在与 OceanBase seekdb 的合作中打造一体化数据库的实践路径。

郑立指出,大量多智能体架构强调 AI 的自主决策与执行,但实际业务推进依然高度依赖人工沟通、确认与协同,这使得“完全自动化”的智能体难以直接落地到真实流程中。为此,Dify 秉持“增强人类能力”的设计理念,让 AI 融入流程、提升效率,而非取代人的角色。

在与 OceanBase seekdb 的合作中,Dify 完成了从多数据库组合到事务一致的统一数据层的升级。一方面,基于 OceanBase seekdb,Dify 自 v1.10.1 起正式兼容 MySQL。另一方面,通过统一的存储与检索架构,OceanBase seekdb 可同时承担元数据库,并提供向量与关键词混合搜索(Hybrid Search)能力,形成开箱即用的一体化部署方案,进一步降低部署与运维复杂度。

DevRel and Founding Member of Second State Miley Fu

DevRel and Founding Member of Second State Miley Fu 则以“Building Cutomizable Agentic Voice AI: Echokit with OceanBase's Hybrid Search”为题进行了分享。

她介绍,WasmEdge 新开源了一款 Agentic Voice AI 产品——Echokit,其强调本地化部署能力,支持完全离线运行,兼顾隐私保护、可控性与高度定制化。在这一过程中,Echokit 已与 OceanBase seekdb 开展合作,将其作为本地数据库用于混合搜索。谈及选择 OceanBase seekdb 的理由,Miley Fu 表示,OceanBase seekdb 的三大优势:无 CDC 延迟、原生 AI 支持与良好 SQL 兼容性,能实现向量、元数据与文本的原子更新,并易于与智能体集成,非常适合实时语音 AI 场景。

Datawhale 内容生态负责人 Amy

来自 Datawhale 的内容生态负责人 Amy 则从社区与教育视角出发,以《让学习导向产业价值,Datawhale 的思考和探索》为题进行分享。作为成立七年的开源学习社区,Datawhale 始终致力于降低技术学习门槛,推动开发者通过实战掌握前沿技能。Amy 表示,这一理念与 OceanBase “开源开放,生态共赢”高度契合。Datawhale 计划与 OceanBase 共同建设 AI+数据库学习中心,降低数据库技术入门难度,助力构建健康、可持续的开发者生态。

从知识赋能到架构落地,开源工具正驱动 AI 应用走向成熟。

TEN Framework 发起人 & 架构师胡岳伟,在《TEN Framework:如何快速搭建带记忆的低延时对话式 AI Agent》演讲中,分享了在实时多模态智能体开发中的实践。

TEN Framework 发起人 & 架构师胡岳伟

TEN Framework 是一款面向实时多模态 AI Agent 的开源开发框架,已在 GitHub 获得近万星,具备真实落地能力。目前,TEN Framework 正在开发 Voice AI Agent 产品,并与 OceanBase PowerMem 开展合作,实现对话上下文的实时同步与记忆管理,为低延迟、高并发的对话场景提供底层支持。

从检索架构演进、一体化数据层构建,到语音 AI 落地、开源教育与框架赋能——五位嘉宾的分享,不仅呈现出 AI 数据底座建设的多元路径,也共同印证了开源协作、生态共建在推动技术走向成熟过程中的核心价值。

圆桌对谈:从 RAG 到 AI 专家共议未来方向

在嘉宾精彩分享之后,两场围绕 AI 时代关键议题的圆桌对话进一步激发了现场的思维碰撞。

在人工智能快速演进的大背景下,RAG 技术正成为推动 AI 能力落地的重要突破点,相关讨论也显得尤为深入。

活动现场,LangChain Ambassador 张海立、 RAGFlow CEO 张颖峰、FastGPT 负责人余金隆、Co-founder of Nowledge Labs 古思为以及 OceanBase AI 平台与应用部负责人吉剑南针对“从 Prompt 到 Skills,RAG 还行不行”这一话题,展开探讨。

多位行业专家从产品实践、技术演进与系统架构等维度切入,认为 RAG 不仅未过时,反而因与 Skill、Memory、数据库等技术的深度融合而更具生命力。成为上下文工程的核心基础设施,并与数据库、技能系统、记忆机制深度融合,推动 AI 应用从“问答玩具”向“生产级工作流”跃迁。

RAGFlow CEO 张颖峰表示,从 RAG 引擎到上下文引擎,技术不变,但其内涵会随着时代的变化而改变。谈及未来 RAG 是否应更多依赖数据库进行多路检索这一话题时,OceanBase AI 平台与应用部负责人吉剑南认为,RAG 应与数据库结合,这也是 OceanBase 提出的“混搜”这一理念的核心所在。Co-founder of Nowledge Labs 古思为则从图数据库视角出发,指出索引结构应贴近知识本质,并支持动态 Agent 检索;FastGPT 负责人余金隆补充说明标量与向量结合的动态检索实践。

在第二场圆桌对话中,南京大学研究生院人工智能课程企业教师谢肖瑜作为主持人,与 Eigent 核心研发工程师、CAMEL-AI 核心成员孙韬,OceanBase Ambassador 程治玮,蚂蚁百灵模型产品负责人边思康和Fellou 创始团队成员孙稼骏针对“Agent 元年之后,真正能用的 AI 长什么样”这一话题展开讨论。

随着AI技术深入现实应用,一个关键议题正引发广泛讨论:人类使用 AI 的门槛是否正在提高?针对这一问题,专家们认为,尽管当前部分 AI 工具仍需要一定配置与学习成本,但技术演进正推动交互方式发生根本性转变,回顾人机交互历史,从 DOS 命令到图形界面,技术门槛始终在不断降低。尤其在当下,大模型能力的显著提升,使得 AI 正变得更易理解与使用。越来越多的产品开始尝试通过界面引导、视觉交互降低操作难度,让非技术用户也能借助 AI 完成复杂任务。

这种“以人为中心”的设计趋势,意味着未来 AI 将不再仅是技术专家的工具,而会真正成为人人可用的普及型能力。在这一过程中,如何让技术适配人的习惯,而非让人适应技术,将成为产品进化的重要方向。

AI Coding 实战上演巅峰对决:13岁少年拿下第二名

此外,本次活动创新设立了 AI Coding 实战环节。OceanBase Ambassador 伊洪以“开源,Agents 以及 AI Coding”为主题,进行了分享,并在现场零代码“手搓” coding agent 。

OceanBase Ambassador 伊洪

在 AI Coding 环节,颁发了“最快合并奖”“最难 pr 奖”“最多合并奖”“最佳创意奖”等 10 项大奖,其中,OceanBase Ambassador 程治玮获“最佳创意奖”,来自上海的 13 岁初二少年张天瑜获得 AI Coding “最难 pr 奖”第二名。

过去,参与开源往往需要先花时间熟悉项目,再完成编码、调试和提交,整体门槛较高。随着 AI Coding 工具能力的提升,开发者在理解代码、生成修改、定位问题和完善提交等环节能获得更多辅助,参与开源的门槛随之下降。

活动前,OceanBase 已在 OceanBase seekdb 的 GitHub 仓库集中开放了 83 个与 OceanBase 及其生态相关的 issue,便于社区开发者参与讨论与贡献。

获得 AI Coding “最难 pr 奖”第二名的张天瑜。此次选择的题目是“为 powermem 添加网页 Dashboard”,需要开发统计 API 和前端页面。前端他凭借两年的 React/Vue 经验独立完成,后端则交给 AI 辅助生成。“让我惊讶的是,AI生成的后端代码一次就跑通了。”

此外,在下午的社区开放麦环节,由 FastGPT、CelHive、CAMEL-AI、Refly.AI、Dify 以及 OceanBase seekdb 的各位技术专家 ,通过现场实操,为大家展示了在各个 AI 平台上构建 Agent 系统和工作流的便捷性。其中最令人印象深刻的是,各平台都纷纷展示了如何通过自然语言来高效地构建 Agent 和工作流,堪称吹响了一场 Agentic 革命的号角。

对于开发者而言,借助 AI 工具快速理解项目、上手的同时,能更专注于创意实现与边界探索,不仅让开发更智能,更让开源共建更可持续、更富创造力,而这也是 AI 时代赋予开源生态的新命题与新机遇。

本次社区嘉年华以技术为纽带,有效激发了社区的创新活力。展望未来,我们诚邀更多开发者与生态伙伴加入,携手拓展开源技术的应用边界与想象空间。

公共资源速递

6 个公共数据集:

  • Sonar Signal 水下声呐信号数据集
  • Diabetes Mexico 墨西哥糖尿病数据集
  • Vehicles OpenImages 车辆图像数据集
  • LightOnOCR-mix-0126 文本转录数据集
  • Delhi Pollution AQI 德里空气质量数据集
  • Chest X-ray Pneumonia 胸部 X 光肺炎数据集

7 个公共教程:

  • DeepSeek-OCR-2 视觉因果流

* Ovis-Image:高质量图像生成模型

  • vLLM+Open WebUI 部署 GLM-4.7-Flash
  • Step3-VL-10B:多模态视觉理解与图文对话
  • TurboDiffusion:图像与文本驱动视频生成系统

* LightOnOCR-2-1B 轻量级高性能端到端 OCR 模型

* Personaplex-7B-v1:实时对话与角色定制语音接口

访问官网立即使用: openbayes.com

公共数据集

1. Sonar Signal 水下声呐信号数据集

Sonar Signal 是一个用于水下物体分类的声呐信号数据集。该数据集适用于二分类任务,目标是区分声呐信号是由岩石还是矿井反射而来。该数据集总计 207 个样本,每个样本包含 60 个连续数值特征。

在线使用:

https://go.openbayes.com/RJhGo

2. Diabetes Mexico 墨西哥糖尿病数据集

Diabetes Mexico 是由墨西哥的国家公共卫生研究所发布的糖尿病数据集,旨在评估墨西哥人群中与糖尿病相关的代谢风险特征。该数据集包含墨西哥个体的社会人口学、人体测量及生物化学信息,主要变量涵盖调查标识符、性别、年龄、居住城市,以及体重、身高、体重指数等体格指标,并包括尿酸、白蛋白、肌酐、总胆固醇、HDL/LDL 胆固醇、甘油三酯、血清葡萄糖、胰岛素和糖化血红蛋白等相关生化指标。

在线使用:

https://go.openbayes.com/gi6tC

3. Vehicles OpenImages 车辆图像数据集

Vehicles OpenImages 来源于 Google 的 OpenImages 大规模公开数据集,专注于车辆检测与定位的图像数据集,旨在支持车辆检测模型的快速高效训练。该数据集包含多种环境、光照条件和视角下的车辆图像,图像预处理为 416×416 分辨率,适用于 YOLO、SSD 和 RetinaNet 等现代目标检测模型提供COCO、YOLO、Pascal VOC 和 TensorFlow 格式的多种注释格式,兼容多种机器学习框架,包含平衡的训练/验证/测试分割,以评估模型性能。

在线使用:

https://go.openbayes.com/Q61aS



数据集示例

4. LightOnOCR-mix-0126 文本转录数据集

该数据集包含训练集与验证集两部分,每个样本对应一个文档页面的文本转录结果,内容涵盖按自然阅读顺序组织的页面文本(输出格式包括 Markdown、LaTeX 数学公式及 HTML 表格等)以及相应的结构化标记,覆盖段落、标题、列表与表格等多类型页面内容。

在线使用:

https://go.openbayes.com/SroyH

5. Delhi Pollution AQI 德里空气质量数据集

Delhi Pollution AQI 是一个面向空气质量分析和预测的环境数据集。该数据集提供了德里 NCR 地区主要城市的每小时空气质量和环境数据,适合用于污染分析、时间序列预测和机器学习应用。数据集拥有超过 200,000 条小时观测样本。

在线使用:

https://go.openbayes.com/IbRsn

6. Chest X-ray Pneumonia 胸部 X 光肺炎数据集

Chest X-ray Pneumonia 是一个从胸部 X 光图像中提取的数值特征数据集。该数据集通过将每张图像转化为结构化的数值特征,包括全局强度统计、纹理描述符(GLCM)、频域特征(FFT)、基于边缘的度量以及局部二值模式(LBP)特征,来支持统计分析和经典机器学习。

在线使用:

https://go.openbayes.com/IbRsn

公共教程

1. DeepSeek-OCR-2 视觉因果流

DeepSeek-OCR 2 是由 DeepSeek 团队推出的第二代 OCR 模型,通过引入 DeepEncoder V2 架构,实现从固定扫描到语义推理的范式转变。模型采用因果流查询和双流注意力机制,能动态重排视觉 Token,更精准地还原复杂文档的自然阅读逻辑。在 OmniDocBench v1.5 评测中,模型综合得分达到 91.09%,较前代提升显著,同时显著降低了 OCR 识别结果的重复率,为未来构建全模态编码器提供新路径。

在线运行:

https://go.openbayes.com/C5oYw


项目示例

2. Ovis-Image:高质量图像生成模型

Ovis-Image 是一个高质量图像生成模型系统,由 AIDC-AI 团队发布的 Ovis-Image-7B 高保真文本到图像生成模型构建。该系统采用多尺度 Transformer 编码器与自回归生成架构,在高分辨率图像生成、细节表现及多风格适配能力上表现卓越。通过优化的噪声采样和 classifier-free guidance 技术,Ovis-Image 能够在 1024x1024 分辨率下生成自然、连贯、细节丰富的图像,支持写实、赛博朋克、动漫、科幻等多种风格。

在线运行:

https://go.openbayes.com/KFcQO

项目示例

3. vLLM+Open WebUI 部署 GLM-4.7-Flash

GLM-4.7-Flash 是智谱 AI 推出的轻量化 MoE 推理模型,兼顾高性能与高吞吐,原生支持思考链(CoT)、工具调用与 Agent 能力。它采用 Mixture of Experts(MoE)架构,通过稀疏激活机制,在保持大模型表达能力的同时,大幅降低单次推理的计算成本。

在线运行:

https://go.openbayes.com/ItzzP


项目示例

4. Step3-VL-10B:多模态视觉理解与图文对话

Step3-VL-10B 由 StepFun 团队发布,是一款面向多模态理解与复杂推理任务的开源视觉-语言基础模型。STEP3-VL-10B 旨在在参数规模受限的前提下,重新定义多模态模型在效率、推理能力与视觉理解质量之间的平衡。尽管参数规模紧凑,该模型在视觉感知、复杂推理以及人类指令对齐等方面表现出色,在多项基准测试中持续优于同规模模型,并在部分任务上可与参数规模大 10–20 倍的模型相竞争。

在线运行:

https://go.openbayes.com/LN9xD


项目示例

5. TurboDiffusion:图像与文本驱动视频生成系统

TurboDiffusion是由清华大学团队开发的高效视频扩散生成系统。该项目基于 Wan2.1 架构进行高阶蒸馏,旨在解决大规模视频模型推理速度慢、计算资源消耗大的痛点,实现了极少步数下的高质量视频生成。该系统基于 rCM 蒸馏技术,将 14B 模型 5 秒视频的生成耗时从分钟级压缩至 2-10 秒,实现百倍以上的效率飞跃。支持 720P T2V 与 I2V  任务,在极速生成下依然保持 SOTA 级的视觉连贯性与画质。

在线运行:

https://go.openbayes.com/8ufT5


项目示例

6. LightOnOCR-2-1B 轻量级高性能端到端 OCR 模型

LightOnOCR-2-1B 是由 LightOn AI 于 2026 年 1 月推出的最新一代端到端视觉语言模型(OCR)。作为 LightOnOCR 系列中的旗舰级版本,它在一个紧凑的架构中统一了文档理解与文本生成功能,拥有 10 亿参数(1B),能够在消费级显卡(约 6GB 显存)上运行。该模型采用 Vision-Language Transformer 架构,并引入了 RLVR 训练技术,实现了极高的识别准确率与推理速度,专为需要处理复杂文档、手写体及 LaTeX 公式的应用场景设计。

在线运行:

https://go.openbayes.com/uxY9d

7. Personaplex-7B-v1:实时对话与角色定制语音接口

PersonaPlex-7B-v1 是 NVIDIA 于 2026 年 1 月发布的 70 亿参数多模态个性化对话模型,面向实时语音/文本交互、长效角色一致性模拟与多模态感知任务。本 Notebook 基于该模型构建,旨在提供一个支持毫秒级响应的沉浸式角色扮演与多模态交互演示系统。

在线运行:

https://go.openbayes.com/aM5GU


项目示例

不管你是 Linux 后端开发、C/C++ 编程,还是运维面试,系统调用和库函数都是大家绕不开的核心知识点。小编发现很多新手(也包括工作多年的)写代码时随手调用的函数(比如 printf、open、fopen),大部分小伙伴们压根就不关心这些函数哪些是系统调用、哪些是库函数,甚至误以为二者是同一概念,结果面试被问倒、排查问题找不到方向。

确实,从咱们普通人的角度来看,系统调用和库函数似乎没有什么区别,它们都是以 C 函数的形式出现,并且两者都为应用程序提供服务。但从实现者角度来看,它们之间是有根本的区别。那么,它们之间到底有哪些不同呢?在说明之前,先简单了解以下系统调用和库函数。

什么是系统调用?

系统调用是操作系统为应用程序提供的一组特殊接口,是用户空间与内核空间之间的关键桥梁。在计算机系统中,内核负责管理硬件资源、调度任务和维护系统安全等核心功能,运行在特权级较高的内核态;而应用程序则运行在用户态,对硬件和系统资源的访问受到严格限制。系统调用充当“翻译官”,允许应用程序通过它向内核发出请求,执行特定操作,并将处理结果返回给应用程序。

咱们举个经常用的典型场景:当应用程序需要读取文件数据时,会直接调用 read 这一系统调用。应用程序会将文件描述符、数据接收缓冲区、预期读取的字节数等关键参数传入 read,随后通过系统调用触发 CPU 特权级切换,从用户态进入内核态。内核会依据传入的参数定位目标文件,从磁盘介质中读取对应数据,并将数据拷贝至应用程序指定的用户态缓冲区,最终把实际读取的字节数作为返回值,传递回用户态的应用程序。

常见系统调用很多,例如:open, close, read, write, ioctl,fork,clone,exit,getpid,access,chdir,chmod,stat,brk,mmap 等,需要包含 unistd.h 等头文件。

那系统调用的具体工作流程什么呢?

答:应用程序发起调用时,会触发内核陷入机制。以 x86 架构为例,通过 int 0x80 这类陷入指令,CPU 从权限受限的用户态,切换至拥有最高权限的内核态。内核会根据系统调用号,在系统调用表中找到对应的内核函数并执行,比如读取文件时就会调用磁盘 IO 相关的内核逻辑。操作完成后,内核将结果返回应用程序,CPU 再切回用户态,程序继续向下执行。

什么是库函数?

库函数用于提供用户态服务。它可能调用封装了一个或几个不同的系统调用(printf 调用 write),也可能直接提供用户态服务(atoi 不调用任何系统调用)。

小编把库函数理解为是预编译的程序代码,存储在共享库或静态库中,用于执行常规编程任务。

常见库函数有:printf,scanf,fopen,fclose,fgetc,fgets,fprintf,fsacnf,fputc,calloc,free,malloc,realloc,strcat,strchr,strcmp,strcpy,strlen,strstr 等,需要包含 stdio.h,string.h,alloc.h,stdlib.h 等头文件。

它俩之间区别:

  • 系统调用通常不可替换,而库函数通常可替换
  • 系统调用通常提供最小接口,而库函数通常提供较复杂功能
  • 系统调用运行在内核空间,而库函数运行在用户空间

因为系统调用属于内核,和库函数不属于内核。因此,如果当用户态进程调用一个系统调用时,CPU 需要将其切换到内核态,并执行一个内核函数。

  • 内核调用都返回一个整数值,而库函数并非一定如此

在内核中,整数或 0 表示系统调用成功结束,而负数表示一个出错条件。而出错时,内核不会将其设置在 errno,而是由库函数从系统调用返回后对其进行设置或使用。

  • POSIX 标准针对库函数而不是系统调用

判断一个系统是否符合 POSIX 标准,关键在于它是否提供了一组适当的应用程序接口,而与这些函数的具体实现无关。因此,从移植性角度来看,使用库函数的移植性优于直接使用系统调用。

  • 系统调用运行时间属于系统时间,库函数运行时间属于用户时间
  • 调用系统调用开销相对库函数来说更大

许多库函数会调用系统调用,但直接调用系统调用的开销较大,主要是因为上下文切换的代价。在用户态和内核态之间切换时,需要保存和恢复 CPU 状态,这消耗时间。库函数通过使用双缓冲技术和缓冲机制来降低这种开销,以文件读写为例,调用库函数可以显著减少系统调用次数,从而提高性能。直接调用系统调用时,每次都需进行上下文切换,导致性能损失。因此,库函数的开销通常小于直接调用系统调用,同时它们也能对系统调用进行优化,提升整体效率。

弄个表格,方便记忆和对比:

什么时候使用系统调用?

  • 需要直接控制硬件或内核资源(如设备驱动开发)。
  • 追求极致性能(但需权衡系统调用开销)。
  • 操作系统内核开发。

什么时候使用库函数?

  • 需要高级功能(如字符串处理、数学运算)。
  • 追求开发效率和可移植性。 避免重复造轮子(
  • 如使用 pthread 而非手动实现线程)。

总结

  • 系统调用是内核的 “底层大门”,是用户态访问内核的唯一通道,开销大、权限高、不可移植;
  • 库函数是用户态的“便捷工具”,基于系统调用封装,部分纯逻辑函数与内核无关,开销小、易用、可移植;
  • 日常开发优先使用库函数,兼顾开发效率和性能;底层开发、性能极致优化场景,可直接调用系统调用。https://mybj123.com/29266.html

前言

在鸿蒙生态逐步向 PC、平板、车机、IoT 全场景扩展的背景下,越来越多开发者开始关注一个现实问题:

如何用最低成本,构建可同时运行在鸿蒙与多平台的应用?

Flutter 作为成熟的跨端 UI 框架,在适配 HarmonyOS 6.0 后,已经具备了完整的工程化能力:
一次开发,多端部署,天然适合鸿蒙“全场景设备”的产品理念。

本文我们不讲复杂架构,不上状态管理,不搞花哨组件,只做一件事:

用 Flutter 在 HarmonyOS 6.0 上,实现一个最基础、最标准、最工程化的列表页面。

目标非常明确:
构建一个带分隔线的基础 ListView,并完全理解每一行代码。


在这里插入图片描述

背景

在真实业务中,列表几乎是出现频率最高的 UI 结构

  • 设置页 → 列表
  • 消息页 → 列表
  • 文件管理 → 列表
  • 日志面板 → 列表
  • 运维系统 → 列表

可以说:

学会 ListView,等于掌握 Flutter UI 的 40%。

而在 HarmonyOS 场景下,列表还有一个额外价值:

  • 大屏设备(PC / Pad)
  • 多窗口
  • 分布式界面
  • 高刷新率

都要求列表组件 性能稳定 + 行为可控 + 样式一致

所以我们从最基础的 ListView.separated 开始,是最工程化、最合理的学习路径。


Flutter × HarmonyOS 6.0 跨端开发介绍

架构关系

在鸿蒙 PC 上运行 Flutter 的本质结构是:

Flutter Widget Tree
        ↓
Flutter Engine
        ↓
Skia / Impeller 渲染
        ↓
HarmonyOS 图形系统 (ArkUI / Surface)

你写的:

ListView(
  children: [...]
)

最终会被 Flutter Engine 转换为:

  • 原生 GPU 绘制指令
  • 在鸿蒙窗口系统中渲染
  • 不依赖 WebView
  • 不走 H5

这意味着:

Flutter 在鸿蒙上是“真原生渲染”,不是套壳。
在这里插入图片描述

开发核心代码

在这里插入图片描述

我们这篇文章的核心只有一个函数:

/// 构建基础列表布局
/// 展示最简单的 ListView 实现,包含分隔线和基本的 ListTile
Widget _buildBasicList(ThemeData theme) {
  final items = ['项目 1', '项目 2', '项目 3', '项目 4', '项目 5'];

  return Container(
    decoration: BoxDecoration(
      borderRadius: BorderRadius.circular(12),
      color: theme.colorScheme.surfaceContainerHighest,
    ),
    child: ListView.separated(
      shrinkWrap: true,
      physics: const NeverScrollableScrollPhysics(),
      itemCount: items.length,
      separatorBuilder: (context, index) => Divider(
        height: 1,
        color: theme.colorScheme.onSurface.withValues(alpha: 0.1),
      ),
      itemBuilder: (context, index) {
        return ListTile(
          title: Text(items[index]),
          onTap: () {},
        );
      },
    ),
  );
}

这个函数本质上解决了四件事:

  1. 数据源定义
  2. 容器样式
  3. 列表渲染策略
  4. 每一行的 UI 结构

我们逐层拆解。


一、数据源:items 列表

final items = ['项目 1', '项目 2', '项目 3', '项目 4', '项目 5'];

这是一个最简单的 静态数据源,但它抽象出了真实业务中最重要的概念:

ListView 永远只关心一个东西:itemCount + itemBuilder

真实业务中你会换成:

  • 接口返回的数据
  • 数据库查询结果
  • WebSocket 推送数据

但 ListView 的用法完全不变。


在这里插入图片描述

二、外层容器:Container + BoxDecoration

return Container(
  decoration: BoxDecoration(
    borderRadius: BorderRadius.circular(12),
    color: theme.colorScheme.surfaceContainerHighest,
  ),

这一层在鸿蒙适配中非常关键。

1. 为什么不用直接 ListView?

因为鸿蒙设计语言(Harmony Design)强调:

  • 模块化卡片
  • 圆角容器
  • 表面层级(Surface)

所以标准写法是:

列表外一定包一层“语义容器”

这样才能:

  • 控制圆角
  • 控制背景色
  • 控制阴影 / 层级
  • 和 ArkUI 设计风格一致

三、ListView.separated:工程级推荐写法

ListView.separated(
  itemCount: items.length,
  separatorBuilder: ...
  itemBuilder: ...
)

这是 Flutter 中 最推荐用于业务列表的写法

相比:

  • ListView(children: [])
  • ListView.builder(...)

separated 的优势是:

特性ListView.separated
自动分隔线
懒加载
性能友好
UI 结构清晰
适合复杂业务

四、分隔线:Divider 的工程含义

separatorBuilder: (context, index) => Divider(
  height: 1,
  color: theme.colorScheme.onSurface.withValues(alpha: 0.1),
),

这一行非常“专业”。

1. 不写死颜色,而用 Theme

这是鸿蒙跨端开发的关键原则:

永远不要写死颜色,永远使用 Theme。

因为:

  • 鸿蒙支持深色模式
  • 支持动态主题
  • 支持系统级换肤
  • 支持多品牌定制

这一行:

theme.colorScheme.onSurface.withValues(alpha: 0.1)

代表:

使用当前主题下“文字颜色”的 10% 透明度作为分割线

这在设计系统里叫:

Semantic Color(语义色)

而不是 Hard Code。


五、ListTile:最标准的列表行组件

return ListTile(
  title: Text(items[index]),
  onTap: () {},
);

ListTile 是 Flutter 官方提供的:

企业级标准列表行组件

默认自带:

  • 左右 padding
  • 行高规范
  • 触摸反馈
  • 无障碍语义
  • 键盘导航支持(PC 端)

在鸿蒙 PC 场景下尤其重要:

  • 自动支持鼠标 hover
  • 自动支持键盘 focus
  • 自动支持触控点击

你什么都不用写。


在这里插入图片描述

六、两个关键参数:shrinkWrap + physics

shrinkWrap: true,
physics: const NeverScrollableScrollPhysics(),

这是非常典型的 嵌套列表写法

含义是:

  • 这个 ListView 不自己滚动
  • 高度由内容撑开
  • 通常用于:

    • 列表嵌套在 Column
    • 放在页面中间模块
    • 外层还有主滚动容器

在鸿蒙大屏页面中,这是最常见结构

Scaffold
 └─ SingleChildScrollView
     └─ Column
         ├─ Header
         ├─ Card
         │   └─ ListView (shrinkWrap)
         ├─ Footer

实际运行效果(HarmoList)

在 HarmonyOS 6.0 PC 上运行后效果是:

  • 圆角卡片
  • 浅色背景
  • 五行列表
  • 细分隔线
  • 点击有波纹反馈
  • 风格与鸿蒙系统设置页高度一致

视觉风格非常接近:

系统设置 / 文件管理 / 设备管理界面

这就是 “鸿蒙感”UI 的核心来源


心得(工程经验)

通过这个最简单的例子,其实已经体现了三条非常重要的工程原则:


1. Flutter 在鸿蒙不是玩具,是工程级方案

它不是 Demo 框架,而是:

  • 可跑生产系统
  • 可做复杂 UI
  • 可支撑大屏交互
  • 可适配分布式设备

2. ListView 是所有复杂页面的基础单元

任何复杂页面:

  • 设置页
  • 运维后台
  • 设备控制台
  • AI 管理界面

最终拆解后都是:

Header + ListView + Footer

3. Theme 是鸿蒙跨端的灵魂

不用 Theme = 一定翻车:

  • 深色模式崩
  • 品牌定制崩
  • 多设备风格不统一

这行代码价值极高:

theme.colorScheme.surfaceContainerHighest

它代表的是:

“让系统自己决定颜色,而不是我来决定。”

这是专业工程师和 Demo 工程师最大的区别。


总结

通过 HarmoList 这个极简示例,我们完成了:

  • Flutter 在 HarmonyOS 6.0 上的基础 UI 落地
  • 一个标准工程级 ListView 构建方式
  • 理解了 ListView.separated 的真实价值
  • 掌握了鸿蒙风格 UI 的核心设计思想

这段代码虽然只有几十行,但它背后代表的是:

Flutter × HarmonyOS 跨端开发的最小可行工程模型(MVP)

后续无论你要做:

  • 设置系统
  • 文件管理器
  • 运维控制台
  • 设备面板
  • AI 管理后台

所有复杂 UI,90% 都是从这个结构进化出来的。

一句话总结:

真正的跨端工程能力,不是炫技组件,而是把最简单的列表写到“专业级”。

在这里插入图片描述

通过 HarmoList 这个最基础的示例可以看到,Flutter 在 HarmonyOS 6.0 上的开发体验已经非常成熟,其 UI 构建模式与传统 Android / iOS 几乎完全一致,但在鸿蒙全场景设备体系下具备更强的延展性。从工程视角来看,一个看似简单的 ListView.separated,实际上已经完整体现了跨端开发中最关键的几个能力:数据驱动渲染、语义化主题适配、组件级 UI 复用以及面向大屏与多输入方式的交互支持。

更重要的是,这种写法并不是 Demo 级技巧,而是可以直接复用于真实业务系统的“标准工程模板”。无论是设置页、管理后台,还是设备控制面板,本质上都可以从这一基础结构演进扩展。可以说,真正掌握 Flutter × HarmonyOS 的第一步,并不是复杂架构设计,而是把这种最基础的列表组件写得足够规范、足够工程化、足够可复用。

作者:赵雁松,周岩珏,李志强,周永康,刘军

前言:AI 数据分析的“最后一公里”

在企业数字化转型的浪潮中,我们发现很多公司依然面临着“数据深渊”:业务人员想看数据,却受限于复杂的 SQL 语法;开发者虽然尝试了 Text-to-SQL,但生成的代码逻辑常有偏差,同时也无法应对复杂的统计分析、根因定位等场景。

DataAgent 应运而生。 这不是简单的指令翻译器,而是我们基于 Spring AI Alibaba 生态构建的一位“虚拟 AI 数据分析师”。它能够像专家一样思考、规划、纠错,并最终输出一份带图表、带逻辑、带深度洞察的行业级报告。

从架构上,DataAgent 是一款基于 Spring AI Alibaba 生态构建的、面向企业级复杂场景的“虚拟 AI 数据分析师”。它通过 Spring AI Alibaba Graph & Agent Framework 构建了一套具备自我规划、工具调用、反思纠错及人类干预能力的数据智能体(Agent),通过 graph、multi-agent 模式将确定性流程与模型推理结合在一起,搭建了一套兼具流程确定性与智能化的数据智能体产品。

降维打击:为什么 DateAgent 不止是 Text-to-SQL?

image

整体架构

image

核心黑科技:DateAgent 是如何解决企业难题的?

我们不只是在写代码,而是在解决企业数据决策中的“深水区”难题。以下是 DataAgent 攻克研发痛点、实现架构突破的几大核心战役。

4.1 人类反馈机制 (Human-In-The-Loop)

  • 遇到问题: 担心 AI 智商掉线?一个错误的执行计划可能瞬间拖垮生产库,甚至“一步错步步错”。
  • 解决方案:

    • 入口:运行时请求参数 humanFeedback=true(GraphController → GraphServiceImpl)
    • 数据字段:agent.human_review_enabled 用于保存配置,运行时以请求参数为准。
    • 图编排:PlanExecutorNode 检测 HUMAN_REVIEW_ENABLED,转入 HumanFeedbackNode
    • 暂停与恢复:CompiledGraph 使用 interruptBefore(HUMAN_FEEDBACK_NODE),无反馈时进入“等待”,反馈到达后通过 threadId 继续执行。
  • 反馈结果: 给 AI 穿上约束衣!同意、修改或驳回,都在你一念之间。让 AI 既有速度,又懂规矩。

image

image

4.2 Prompt 动态配置与自动优

  • 遇到问题: 修改一句 Prompt 就要重启系统?不同模型对 Prompt 脾气不同,一套模板走天下根本行不通。
  • 解决方案:

    • 配置入口:/api/prompt-config/*,数据表 user_prompt_config
    • 作用范围:支持按 agentId 绑定或全局配置(agentId 为空)。
    • Prompt 类型:report-generatorplannersql-generatorpython-generatorrewrite
    • 自动优化方式:ReportGeneratorNode 拉取启用配置(按 priority 与 display_order 排序),通过 PromptHelper.buildReportGeneratorPromptWithOptimization 拼接“优化要求”。
    • 当前实现重点:报告生成节点已落地优化;其他类型为预留能力。
  • 获得效果: 像配置 Excel 一样调优 AI。运维人员无需重启,即可让 DataAgent 瞬间从“菜鸟分析师”变身“首席架构师”。

image

image

4.3 深度 RAG 与混合检索增强

  • 遇到问题: 纯向量检索常召回一堆废话?AI 不认识你的业务缩写?表结构太复杂,AI 搜不到。
  • 解决方案:

    • 查询重写:EvidenceRecallNode 将多轮上下文与用户问题组装为检索指令,调用 LLM 生成 standaloneQuery,避免上下文遗漏与歧义。
    • 召回通道:AgentVectorStoreService 作为统一入口,默认走向量检索;开启混合检索后走 AbstractHybridRetrievalStrategy,将“向量召回 + 关键词召回”进行融合。(用户需要提供混合检索实现。当前默认只支持 es)
    • 召回过滤:DynamicFilterService 生成基于智能体与知识类型的过滤条件,限制检索范围,避免跨智能体串库。
    • 文档类型:业务知识(business_knowledge)+ 智能体知识(agent_knowledge)两类,按 agentId/type 元数据过滤后合并为 evidence,注入后续 prompt。
    • 关键配置:spring.ai.alibaba.data-agent.vector-store.enable-hybrid-search 控制是否开启混合检索;相似度阈值与 TopK 通过向量库配置项控制(如 top-ksimilarity-threshold)。
    • 输出形式:evidence 文档以标题/摘要/片段形式汇总,作为 EvidenceRecallNode 输出内容进入后续规划于 SQL 生成阶段。
  • 获得效果: AI 拥有了老员工的“直觉”。它能秒懂你的业务逻辑,即便表名全是乱码,它也能精准命中。

image

image

4.4 容器化 Python 执行引擎

  • 遇到问题: SQL 只能算数,不能预测。想看趋势图、做线性回归?SQL 此时显得苍白无力。
  • 解决方案:

    • 代码生成:PythonGenerateNode 根据计划与 SQL 结果生成 Python。
    • 代码执行:PythonExecuteNode 使用 CodePoolExecutorService(Docker/Local/AI 模拟)。
    • 执行配置:spring.ai.alibaba.data-agent.code-executor.*(默认 Docker 镜像 continuumio/anaconda3:latest)。
    • 结果回传:执行结果写回 PYTHON_EXECUTE_NODE_OUTPUTPythonAnalyzeNode 汇总后写入 SQL_EXECUTE_NODE_OUTPUT,用于最终报告。
  • 获得效果: 赋予 AI 科学家级的建模能力。不仅能提取数据,还能输出带图表、带算法、带深度预测的高质量产出。

image

image

4.5 流式输出 (SSE) 与多轮对话管理

  • 遇到问题: 分析任务耗时太长,用户盯着屏幕转圈圈,以为系统挂了。
  • 解决方案:

    • 流式输出:GraphController SSEGraphServiceImpl 流式处理。
    • 文本标记:TextType 在流中标记 SQL/JSON/HTML/Markdown,前端据此渲染。
    • 多轮对话:MultiTurnContextManager 记录“用户问题+规划结果”,注入到后续请求。
    • 模式切换:spring.ai.alibaba.data-agent.llm-service-type 支持 STREAM/BLOCK
  • 获得效果: 极致的交互快感!让用户亲眼看到 AI 正在如何“思考”与“推演”,每一秒都有获得感。

image

image

4.6 MCP 服务器发布与多模型调度

  • 遇到问题: DataAgent 虽好,但只能在自研系统用?想集成到 Claude 或 IDE?适配成本高到吓人。
  • 解决方案:

    • MCP:McpServerService 提供 NL2SQL 与 Agent 列表工具,使用 Mcp Server Boot Starter。
    • 多模型调度:ModelConfig 配置模型,AiModelRegistry 缓存当前 Chat/Embedding 模型并支持热切换(同一时间每类仅一个激活模型)。
    • 已内置工具:nl2SqlToolCallback、listAgentsToolCallback
  • 获得效果: 无处不在的 AI 生产力。它是你的数据中心,也是你办公软件里随叫随到的超强插件。

image

image

4.7 多数据源接入

  • 遇到问题: 企业数据散落在 MySQL、PostgreSQL 等各类库中,跨库取数像是在做“情报搜集”,配置繁琐且标准不一。
  • 解决方案:

    • 元数据存储:数据源配置写入 datasource,智能体绑定写入 agent_datasource,选表写入 agent_datasource_tables,逻辑外键写入 logical_relation
    • 类型扩展:BizDataSourceTypeEnum 定义数据源类型;对应的 Accessor + DBConnectionPool 负责不同数据库协议与方言的访问。
    • Schema 初始化:AgentDatasourceController 触发初始化,SchemaService 通过 AccessorFactory 拉取表/列/外键并写入向量库。
    • 运行时选择:DatabaseUtil 从当前智能体获取激活数据源,动态选择 Accessor 执行 SQL。
    • 约束:同一智能体同一时间仅允许启用一个数据源(AgentDatasourceService.toggleDatasourceForAgent)。
  • 获得效果: 一个智能体,纵览全司数据!无论数据在哪儿,DataAgent 都能精准“路由”。它是数据孤岛的终结者,让跨库分析像查询单表一样简单。

image

image

4.8 报告生成与摘要建议

  • 遇到问题: 查出来一堆数字有什么用?领导要的是洞察,是结论,是能直接发在群里的 HTML 报告。
  • 解决方案:

    • 报告节点:ReportGeneratorNode 读取计划、SQL/Python 结果与摘要建议(summary_and_recommendations)。
    • 输出格式:默认 HTML,plainReport=true 输出 Markdown(简洁报告)。
    • 优化提示词:自动拼接优化配置后生成报告。
  • 获得效果: 把分析师的一天缩短为 10 秒。从查数到成稿,DataAgent 承包了所有体力活,让你只负责最后的一锤定音。

image

4.9 NL2SQL 转换, 语义模型,逻辑外键引擎

  • 遇到问题: 纯大模型写 SQL 经常“盲目自信”,不是字段写错,就是不懂业务术语。语法错误导致的执行中断更是家常便饭。
  • 解决方案:

    • 语义模型层:通过管理端定义的术语映射规则,在生成阶段强制约束。
    • 两阶段校验:SqlGenerateNode 生成后接 SemanticConsistencyNode 检查语义一致性。
    • 自愈循环:SqlExecuteNode 捕获执行错误并反馈给 Graph 状态机,触发重定向至重写节点进行纠错。
    • 逻辑外键:写入外部的业务逻辑的外键,不写入业务数据库。增强对表的理解能力。
  • 获得效果: 让 AI 拥有“职业分析师”的严谨。 告别报错,告别幻觉。它不仅懂 SQL 语法,更懂你的业务逻辑,让每一次查询都精准命中。

4.10 API Key 与权限管理

  • 遇到问题: 接口裸奔?权限失控?想对外开放能力却怕费用爆炸或数据泄露。
  • 解决方案:

    • 管理端:AgentController 支持生成、重置、删除与启用/禁用 API Key。
    • 数据字段:agent.api_key 与 agent.api_key_enabled
    • 调用方式:请求头 X-API-Key
    • 注意:默认不开启鉴权拦截;生产需开启 spring.ai.alibaba.data-agent.api-key.enabled=true
  • 获得效果: 生产级安全防护。让你的 DataAgent 不仅是业务利器,更是安全可控的企业级数字资产。

image

image

结语:让数据价值触手可及

DataAgent 的核心价值在于,它不仅仅是完成了一次查询,而是将“数据处理的工程化”与“大模型的推理能力”深度结合。结合 Spring AI Alibaba  的 Graph 编排与 Agentic 推理能力,DataAgent 将确定性流程与模型推理结合在一起,将原本碎片化的分析过程,转化为了兼具流程确定性与智能化的数据智能体。

未来,数据不再是冷冰冰的行列,而是每一位业务决策者都能随手调用的“智库”。

想了解更多关于 DataAgent 的技术实现细节? 欢迎搜索钉钉群,群号: 154405001431,加入我们的开发者讨论群,共同探索 AI 的无限可能!

相关资源:

基本介绍

我做了一款基于小模型的拍照识别物品的 APP ,先录入物品的特征,可以从四个角度各拍一张照片,让模型能记住这个物品的特征。

然后点击 [识别特征] ,对着要识别的物品拍一张照片,点击识别,即可根据相似度进行查询。相似度的阈值可以在设置里面调整。

项目代码地址: https://gitee.com/mktime/object-detect

效果演示

APP 首页

拍照识别

世界范围内数字化进程正在不断加快,全球化与数字化开始深融合。在此等时代背景下,大型企业的业务版图正趋于多元化,突破单边限制。域名也是如此,从独立的域名,逐渐扩展至集团官网、独立子品牌、区域业务站点、品牌电商等。随着企业规模的不断增大和业务版图的扩充,数字资产逐渐分布至企业旗下数十甚至上百个域名。面对数量众多的网站,管理难度呈现指数级增长。单以数字证书而论,从申请到部署,从监控到续期,数百个域名的管理难度可想而知,稍有疏漏便可能引发连锁效应,让企业面临漏洞威胁与业务中断风险。JoySSL市场部负责人曾多次提到,单域名证书的管理模式已不适合大型企业的复杂架构,不仅效率低下,还会造成企业额外的成本支出。多域名SSL证书则是化繁为简,实现企业运维管理简化、优化成本结构的战略工具,是大型企业拥抱数字生态的基础。

多对一高效管理凸显证书核心优势

拥有多域名的大型企业,SSL证书通常缺乏统一管理视角,易造成资产无法统筹、证书过期以及安全策略不一致等诸多问题。多域名SSL证书可实现集中式管理,摒弃“证书分散现象”,打造统一的管理体系,对所有受保护的域名实现统一监控、快速续约与策略管理,告别碎片化管理模式。

多域名SSL证书可完成高效的成本管理,优化总体拥有成本,节约资源与人力,减少了证书审批、部署与日常运维的成本消耗,使企业团队能够专注于战略性的任务。

超越技术 赋能大型企业开展业务

部署多域名SSL证书,已成为企业集团化与多品牌战略的安全统一保障,为各子品牌网站提供统一且可信的高级安全标识,增强市场对品牌专业形象的认可,维护企业整体声誉。面对严格的审计标准,通过多域名证书,企业可向审计机构展示全面的安全管理措施,从而显著简化合规流程。

多域名证书支持收购整合与业务创新的快速反应能力,从而实现安全而高效的资源整合。此外,证书可提供标准化且高安全性的保护,确保生态伙伴服务的稳定性。

多域名SSL证书优化管理解决方案

OV及EV证书可确保企业在身份验证方面达到最高标准,提升公众对企业可信度的感知,提升品牌价值。此外,面对复杂的网络环境,JoySSL自动化证书管理平台能够实现证书与域名的高效识别、批量化部署、智能化监控预警,以及全流程的自动续期功能,使证书管理无缝嵌入企业数字化生态系统,保障企业数字基础设施的安全稳定运行。

以简约之道主动构建网络安全架构

多域名证书以化繁为简之道,配合专业的管理方案,推动企业从被动应对转为主动构建安全架构,通过高度集成的系统,使众多域名协同运行,提升整体防御能力。不仅是技术升级,更是企业管理理念的深刻蜕变。

近一周行情呈现出一种无序混沌的状态,硬科技与资源股回撤跌的比较狠,幸好没碰。午盘后拉了消费板块,我手里的消费电子或许能跟着喝口汤。

我的持仓:2 个医药+1 个医疗器械+2 消费电子+1 自动驾驶+1 美容护理
今天账户+3%跳水到+1%,还行,满足了。

Cursor 近日公布了 Agent Trace 开放规范草案,目标是解决 AI 生成代码在软件项目中的归属与标注问题。该提案以 RFC 形式发布,定义了一种厂商中立的格式,用于在版本控制系统中记录 AI 与人类协作产生的代码贡献。

基于其在 AI 辅助编程工具方面的实践经验,Cursor 发现,代码变更过程中对上下文的追踪能力仍然明显不足。以常见的 git blame 等工具为例,它们只能显示某一行代码“何时被修改”,却无法说明这次修改是由人类完成、由 AI 完成,还是二者协作的结果。Agent Trace 正是为了解决这一缺口,试图以结构化、可互操作的方式捕获这些关键信息。

从技术角度看,Agent Trace 是一套数据规范,使用基于 JSON 的 trace record(追踪记录)来关联具体的代码范围,以及背后的对话过程和参与者。代码贡献可以在文件级或行级进行追踪,按会话进行分组,并被标注为“人类”、“AI”、“混合”或“未知”。该模式还支持为 AI 生成的代码附加可选的模型标识,从而在不绑定具体厂商的前提下,实现更精确的归属记录。

此处输入图片的描述

在设计上,这一规范刻意保持了对存储方式的“中立性”。Cursor 并未规定追踪记录必须存放在哪里,开发者可以根据自身需求,将其保存为普通文件、git notes、数据库记录,或采用其他机制。Agent Trace 同时支持多种版本控制系统,包括 Git、Jujutsu 和 Mercurial,并引入了可选的内容哈希,用于在代码被移动或重构后,依然能够追踪其原始归属。

可扩展性是 Agent Trace 的核心设计目标之一。各厂商可以通过命名空间键(namespaced keys)附加额外的元数据,而不会破坏规范的兼容性。同时,该规范刻意回避了对 UI 形式、代码所有权语义的定义,也不试图评估代码质量或追溯训练数据来源,而是将关注点严格限定在“代码归属”和“可追溯性”本身。

Cursor 还提供了一份参考实现,展示 AI 编程代理如何在文件发生变化时,自动捕获并生成追踪记录。尽管示例基于 Cursor 自家的工具链,但其设计模式被明确定位为可复用方案,适用于其他编辑器和智能代理。

来自开发者社区的早期反馈,普遍强调了这一规范在代码审查和调试流程中的潜在价值。一位 X 用户评论道:

这才是真正在收拾 Agent 生成代码的烂摊子。等不及在 Review 里用了。

另一位用户则从可复现性的角度给予了肯定:

团队一旦搞不清 Agent 为啥跑偏,就会直接停工。Trace 解决了这个痛点,开放得正好。

作为一份 RFC,Agent Trace 明确欢迎社区反馈,同时也有意保留了一些尚未解决的问题,例如在合并(merge)、变基(rebase)以及大规模代理驱动代码变更场景下应如何处理。Cursor 将该提案定位为一个共同标准的起点,而非终极答案,以应对 AI 代理在软件开发流程中日益普及的现实趋势。

原文链接:

https://www.infoq.com/news/2026/02/agent-trace-cursor/

现在小学不布置寒假作业了,需要自己买题给孩子学。我就想是不是可以针对一二年级的知识点做一个在线刷题学习的,再增加一点游戏性。

目前每天让他学几分钟,感觉还是可以的,分享给大家。

地址: https://yinianji.vercel.app/
技术栈:
React 19 + TypeScript + Vite 7
PWA 支持(离线缓存、可安装)
Web Audio API (原生音频)

有什么建议欢迎给我反馈。
tupian1
tupian2
tupian3
tupian4

跨境支付、SaaS、出海电商、金融/加密业务的团队都会遇到用户IP是否来自制裁地区的问题,如果判断失误,损失一定的订单事小,出现合规事故后,解决合规事故的精力、损失的时机才是最难以挽回的东西。

其实这个问题很多相关业务的团队都会注意到,将有关制裁国家的IP封禁,但后来还是会出现合规问题。为什么?

其实这个问题源自于,合规问题并不是一个国家维度的问题,举个“栗子”:
A国家中有①②③个城市,B国家有④⑤⑥个城市,当业务侧处理A、B国家的合规问题时,不是“IP解析 → A/C国家 ≠/= 制裁国 → 放行/拦截”就可以的,因为常常会出现以下情况
1)、A国家不制裁相关产品,但是③城市制止
2)、B国家个人放行,但加密、金融、云服务相关合规

所以单单是指判断国家相关,一定是不够的,所以基本做法应该是:

1、第一层:IP→国家/地区(基础过滤)
国家(Country)→一级行政区(Region/Province/State)→城市(City)

逻辑应该是-IP是否落在被明确制裁的地理区域内
Country=A
Region=③
→命中制裁

这一步依赖的是IP地理定位数据的精细度,是否能做到“地区级别”,导入IP数据云IP地址查询定位库,足够用了。

2、第二层:反规避判断(非常容易被忽略)
制裁地区用户不会老老实实用本地IP,常见规避方式包括:
V口N/Proxy、云厂商出口IP、Tor/匿口名网络、卫星网络

所以可以导入IP数据云的风险画像系统:
1)、IP是否为代口理/V口N/IDC/云IP
2)、IP ASN 是否异常
典型策略是:
制裁业务=地理命中+风险IP命中 → 拒绝或人工审核
跨境业务使用IP数据云IP地址查询定位库判断用户IP是否来自制裁地区?.png

!注意项

1)、只用免费IP查询接口
免费库:
地区精度不足(只到国家)
制裁地区更新滞后(版本落后)
免费≠可合规使用(有一些国家需要查看合规IP信息的来源,作为合规证明)

2)、规则写死在代码里
制裁名单是动态变化的(信息更替不及时,触发合规制裁):
地区新增
限制升级
规则一定要可配置、可更新

最近看到了很多关于 Antigravity 写 commit 很难的评论

我有一个比较成熟的方案,这个方案写的又快又准

大家可以参考一下

1. 下载一个通义灵码的插件

2. 关闭通义灵码的其他功能,只保留代码 commit 生成

3. 使用通义灵码 commit 生成后提交