GitHub开源观察｜开源项目·热门仓库·开发者

Kaneo：极简开源项目管理工具

Kaneo 是一款主打「少即是多」的开源项目管理工具，MIT 许可。它针对现有项目管理平台功能臃肿、通知和复杂流程干扰实际工作的问题而设计，强调界面干净、专注任务本身，并支持自托管以保证数据自主可控。

项目提供多种部署方式：可用 drim CLI 一键部署，自动配置 HTTPS 和数据库；也可用 Docker Compose 快速启动，一条命令拉起 Kaneo 和 PostgreSQL；Kubernetes 环境则提供 Helm chart。开发模式支持 pnpm 启动前后端服务。

对受够 Jira 等重型工具、希望数据留在自己手里的团队来说，Kaneo 提供了一个轻量替代方案。它把「不干扰工作」作为设计核心，每个功能都对应真实需求，而非演示效果。

项目当前处于早期阶段，社区通过 Discord 和 GitHub Issues 交流。官方欢迎提交 bug、改进文档或参与代码贡献，也接受赞助以支持持续开发。

GitHub

#GitHub #开源 #Kaneo #项目管理 #自托管 #MIT
@GitHubTrendingHub

自由职业报价为何总被低估

一个 300 美元的“快速仪表盘”项目，预估 8 小时，看似时薪 37.5 美元。但算上启动会议、数据整理、两轮修改、支付手续费和税费预留，实际耗时 13 小时，到手时薪可能跌破 20 美元。问题不只是范围蔓延，而是报价体系不完整。

这套开源报价工作流提供了一套可复用的方法：按全流程工时而非纯开发时间计价，用复杂度系数区分难易任务，明确修改轮次并预留缓冲，把紧急度和风险单独计费，同时强调净现金除以实际工时才是有效时薪。配套提供双语 Excel 与 Google Sheets 模板，含报价构建器、利润看板、客户利润记录和范围蔓延费率表。

具体报价步骤：

• 先估算发现需求
• 客户沟通
• 文件整理
• 质量审查
• 交付
• 开票等全部环节的工时；再用 1.0x 到 1.4x 的复杂度系数调整难度；为包含的修改轮次预留至少 5% 的工时缓冲；把付费素材
• 分包商
• 差旅
• 数据采购等直接成本计入；最后用定金和额外工时费率保护现金流

核心原则是报价应作为谈判底线而非上限。若项目为客户创造的价值显著更高，可在底线之上加价，但必须先清楚底线在哪里。这套系统还提供免费的双语检查清单和定价说明，以及完整的报价与利润计算器。

这套方法适合自由职业者、独立开发者和接私活的技术人员，帮助在每次报价前系统评估真实成本，避免高估时薪、低估隐性投入。

GitHub

#GitHub #开源 #自由职业 #报价 #定价 #FreelancerPricing
@GitHubTrendingHub

xbatis 1.10.7 发布，MyBatis 生态轻量 ORM 再更新

xbatis 是一款面向 MyBatis 的轻量级 ORM 增强工具，主打简化持久层开发。官方称其 API 简洁、构建 SQL 能力强，单表、连表乃至不想写连表操作的场景下，可帮助开发者减少约三分之一甚至三分之二的持久层代码量。

本次 1.10.7 为维护性小版本，主要修复了 distinct 多列在 count 场景下的优化错误，并新增 count 相关优化。对于正在使用 MyBatis 且希望减少手写 SQL 与 Mapper 样板代码的团队，值得关注。

1.10.7 更新要点：
• 修复 distinct 多列在 count 时优化错误的问题
• 新增 count 优化相关能力

项目定位：在 MyBatis 基础上提供更简单的 API 封装，适合追求开发效率、希望精简持久层代码的 Java 开发者。即便当前 AI 辅助编码普及，对于需要长期维护的项目，一款顺手且稳定的 ORM 工具仍有其价值。

GitHub

#GitHub #开源 #xbatis #MyBatis #ORM #Java
@GitHubTrendingHub

canvas-editor 富文本编辑器发布 1.0

canvas-editor 是一款基于 Canvas 渲染的富文本编辑器，作者在 1723 天前提交第一行代码，历经 1460 次提交后正式发布 1.0.0 版本。

1.0 的发布伴随着一个持续 1556 天的 issue（#41）关闭。该 issue 于 2022 年 4 月 28 日提出，内容是跨页表格在修改列宽时无法同步，经过 39 条讨论后随 1.0 版本一并解决。

对需要处理复杂文档排版、尤其是跨页表格场景的开发者来说，这个版本意味着编辑器在表格分页与列宽同步方面已趋于稳定，适合在文档类应用中评估接入。

GitHub

#GitHub #开源 #canvaseditor #富文本编辑器 #Canvas #表格分页
@GitHubTrendingHub

SemaKazi 前端启动：无框架纯原生实现

SemaKazi 是一个面向肯尼亚非正式行业工人（电工、木匠、机械师、裁缝）的可验证信誉平台。第一阶段后端已完成，包含认证、个人资料、工作证明、评价和徽章系统。现在进入第二阶段——前端开发。

作者刻意选择不用 React、不设构建步骤，仅用 HTML、CSS 和原生 JavaScript 配合 fetch 调用 API。对这类规模的项目，引入框架只会增加仪式感而非实际价值。先搭建共享骨架：api.js 统一封装所有后端调用，nav.js 根据登录状态切换导航链接，style.css 提供一致的设计样式。随后完成注册和登录页面，注册时按角色显示对应字段，登录后存储 JWT 并跳转至尚未开发的控制台页面。

开发中遇到的主要问题是目录结构：注册和登录页面位于 pages/ 子目录，内部相对路径需多一层 ../ 前缀。作者强调这属于"不熟悉而非困难"，仔细检查五分钟即可解决。工作流程延续第一阶段规范：每个功能独立分支、每个文件单独提交、合并前需通过本地测试。

下一步计划是搜索页面、技工个人资料视图，以及认证页面当前跳转的控制台。仓库已公开，可随时跟进提交历史。
@GitHubTrendingHub

用MCP让Claude自动发布博客

一位开发者分享了他用MCP（Model Context Protocol）构建自定义服务器，让Claude自动完成博客草稿整理并发布到Dev.to的完整调试过程。

MCP是一种让AI模型调用外部工具的协议。作者搭建了两个服务器：官方filesystem服务器让Claude读写本地文件，以及自建的devto服务器，封装了Dev.to API用于发布文章。最终效果是，只需对Claude说"读取某文件夹的草稿、润色后发布为草稿"，它就会自动完成整个流程。

过程中踩了不少环境配置的坑：PowerShell安装uv后需重开终端才能识别；Python版本需固定3.10以上才能满足MCP SDK要求；PyPI上存在同名无关包，需显式指定版本范围mcp[cli]>=1.2.0,<2.0.0才能装到真正的SDK；Claude Desktop的配置文件需注意JSON嵌套结构，且Windows下要用完整路径启动命令。

作者总结，真正的难点不在MCP协议本身，而在于PATH、Python版本、包名冲突等基础环境问题。一旦环境就绪，核心代码不过20行Python。这个案例对想用MCP自动化工作流的开发者有参考价值，尤其是Windows环境下的配置细节。

#GitHub #开源 #MCP #Claude #DevTo #Python #AI自动化
@GitHubTrendingHub

Furion v4.9.9.52 发布，新增 HTTP 请求便捷写法

Furion 是一个旨在让 .NET 开发更简单、更通用、更流行的应用框架。本次 v4.9.9.52 版本为维护性小版本更新。

本次更新主要新增了 HTTP 远程请求的 Action<HttpRequestBuilder> 操作符支持，允许将 HttpRequestBuilder 隐式转换为 Action<HttpRequestBuilder>，简化远程调用时的配置写法。对使用 Furion 进行 HTTP 客户端集成的开发者来说，代码可以更简洁。

完整更新日志见官方文档。

#GitHub #开源 #Furion #dotNET #CSharp #开发框架
@GitHubTrendingHub

tuicr：终端里的代码审查工具

tuicr 是一个带 vim 键位的代码审查 TUI，发音类似 "tweaker"。它把 GitHub 风格的连续 diff 搬进终端，让你在一个流里滚动浏览所有变更文件，支持行级、范围级、文件级和审查级评论，审查进度按文件或 hunk 粒度持久化保存。

审查完可以直接把评论推送到 GitHub 或 GitLab 成为真正的 PR/MR 审查，也可以复制成结构化 markdown 交给 Claude、Codex、Cursor 等编码代理，或通过 --stdout 管道给其他进程。支持 git、jj 和 mercurial，可审查未提交改动、commit 范围或任意 GitHub PR / GitLab MR。

安装方式：curl -fsSL tuicr.dev/install.sh | sh，或 brew install agavra/tap/tuicr，也支持 cargo、mise、nix 和预编译二进制。tuicr update 可一键更新，支持按版本安装。

快速上手：直接运行 tuicr 选择 commit，tuicr -w 审查未提交改动，tuicr pr 125 打开 GitHub PR。TUI 内用 j/k 导航，c 添加评论，y 复制审查结果，:submit 推送到 GitHub 或 GitLab。

配置方面，支持 catppuccin、onedark、gruvbox 等 20 余款内置主题，也可自定义主题和语法高亮。提供 Rust 库 API，方便其他工具基于持久化审查会话做二次开发。

相比 hunk、lumen 等同类工具，tuicr 的优势在于完整的 vim 键位模型、可直接推送行级评论到 GitHub 和 GitLab，以及面向编码代理的 markdown 导出。MIT 许可。

GitHub

#GitHub #开源 #tuicr #代码审查 #TUI #Vim #Rust #GitLab #开发工具
@GitHubTrendingHub

reverse-skill：给 AI 编程助手装上逆向与渗透技能路由

面向 AI 代理的逆向工程与渗透测试技能路由包。当 Claude Code、Cursor 等 AI 编程客户端遇到 APK、二进制文件、前端 JS 加密、CTF 题目或渗透测试目标时，该工具包会自动路由到正确的方法论，检查可用工具并执行可重复的工作流，而不是让 AI 猜测命令。

项目解决了 AI 代理面对具体任务时不知道选 jadx、apktool、Frida 还是 BurpSuite 的问题，覆盖 APK/Android、iOS、二进制逆向、前端 JS、恶意软件分析、渗透测试、CTF 竞赛（含 40+ 子技能）、固件/IoT、漏洞利用、EDR 绕过、API 安全、供应链安全、LLM 安全等场景。支持 Windows、Linux/macOS 及 Kali Linux 平台，主项目采用 MIT 许可证。

GitHub

#GitHub #开源 #逆向工程 #渗透测试 #AI编程助手 #安全研究 #CTF
@GitHubTrendingHub

导入外部 AI Agent 定义前，先过一遍这份审查清单

从公开仓库复制一个 Claude Code 或 Codex 的 agent 定义文件，直接丢进 agents 目录就能用——但跳过审查意味着文件会在你的权限范围内运行，而你对它要做什么一无所知。核心原则：把每个外部 agent 定义当作不可信输入，读完整文件而不是 README，再对照宿主实际授予的权限（Claude Code 看 settings.json）检查它声称要读写和执行的内容。

选候选时，先看自己缺什么，而不是仓库里有什么。把需求压缩成一句话：输入是什么、期望输出是什么、明确禁止什么。压缩不了就暂缓引入。读文件时确认它期望的输入类型、产出形式、引用的每个外部文件和命令、对网络和写权限的假设。一个 MIT 许可的 agency-agents 集合里的真实案例说明问题：frontmatter 里的 color、emoji、vibe 字段对 Claude Code 的加载器毫无意义，只有打开文件才能发现这类落差。别把候选直接放进工具自动监控的目录，先只读暂存。

改动要最小化，把每次修改分成两类：格式调整（名称、frontmatter、位置，机械且必需）和含义变更（删除禁令、扩大权限、改变输出类型，属于本地设计决策，需要负责人和理由）。验证分五步：结构、引用、限权试运行、拒绝行为、路由。agency-agents 自带一个检查脚本，交叉核对 divisions 列表与磁盘目录和 CI 路径过滤器，不一致就构建失败。记录测试输入和观察到的输出，未行使的权限标记为未测试。

采用时就定好谁审下一次更新、何时移除。更新到达时分别读三样东西：当前用的角色、当初要填补的缺口、叠加的本地改动。移除不是失败，但删之前检查谁还在引用它。为每个候选填同一套决策表：与缺口的匹配度、与现有角色的重叠、来源和许可条款、改动差异、试用结果、采用状态。让没参与挑选的人试着证伪这次采用：缺口是否真实、搜索范围是否够广、许可是否在源头确认过、改动是否可回退。

采用后保持两个事实来源：上游原始版本管设计和更新历史，本地版本管你实际批准的权限和调用条件。上游变化时先读原因再应用，不更新也可以是正当决定。本地改进不要描述成上游行为，否则未来 bug 难以归因。

这份清单的七步每步都不贵，它替代的是那个沉默的步骤——「看着没问题，就复制进来了」，而这个步骤在出错时代价最高。适用于任何有真实权限的外部可执行角色定义，不限于 Claude Code 或 Codex。

GitHub

#GitHub #开源 #AI #ClaudeCode #Codex #Agent安全 #开源治理
@GitHubTrendingHub

Furion v4.9.9.51 发布，新增 HTTP 远程请求缓存与配额策略

Furion 是一款 .NET 应用框架，旨在简化开发流程。本次 v4.9.9.51 版本主要围绕 HTTP 远程请求模块带来两项新能力：ETag 缓存与配额策略。

ETag 缓存可减少重复请求、提升响应效率；配额策略则用于控制请求频率与用量，适合对接第三方 API 时做限流管理。对依赖远程接口的 .NET 服务端开发者来说，这两个功能能直接降低编码与运维成本。

本次为常规功能更新，非破坏性变更，现有项目可平滑升级。

#GitHub #开源 #Furion #dotNET #HTTP #缓存 #限流
@GitHubTrendingHub

微软 Foundry 主控、Bedrock 远端：跨云 A2A 冒烟测试通过

开发者 xbill 发布了一项跨云互操作测试结果：以微软 Foundry 作为主控协调器，通过 MCP 调用本地汇率基线，再经 A2A 协议调用亚马逊 Bedrock AgentCore 作为远端专家，该方向已于 2026 年 7 月 30 日端到端跑通。此前作者只验证过反向拓扑（AgentCore 主控、Foundry 远端），单一方向的跨云结论说服力不足，本次补上了另一方向的覆盖。

测试输入为 100 USD 转 EUR，三种基准模式均通过：MCP 单独路径返回 87.13800 EUR（适配器耗时 359 ms），A2A 单独路径返回 87.138 EUR（25,105 ms），双路径并发验证模式报告相对差值为 0、判定一致。仓库同时通过 66 项确定性测试，1 项可选集成测试因缺少外部依赖被跳过。

关键设计是让框架无关的代码负责算术与校验，而非交给大模型。协调器用 Python Decimal 计算两条路径的转换金额差值，相对差值不超过 0.005 即判定一致。模型只负责理解意图并选择工具调用，不参与任何数学运算。应用层仅依赖两个接口：MCP 支撑的汇率工具和 A2A 支撑的远端货币代理，微软 Agent Framework 与 Foundry 托管、Strands 与 AgentCore 均位于接口之外，因此翻转云厂商无需重写领域服务。

真正的跨云难题在认证层。AgentCore 默认的 IAM/SigV4 授权对 AWS 调用方适用，但 Foundry 托管的容器没有 AWS 凭证。本次改用自定义 JWT 授权器加 Cognito 机器对机器客户端，协调器的 A2A 适配器现已支持 OAuth 客户端凭证模式，缓存令牌至过期前并保留静态 Bearer 支持。

测试过程中暴露了五类实际问题：A2A 客户端与 AgentCore 服务端依赖不同代际的 SDK（1.x 对 0.3），通过分别固定版本解决；IAM 授权无法跨云，改用 JWT 后解决；默认 10 秒超时对冷启动跨云路径过短，首次调用在 10,010 ms 超时，调整至 60 秒后 A2A 调用在 25.1 秒完成；Foundry 源码构建找不到镜像，改用 Azure 容器注册表中固定摘要的预构建镜像并配置项目托管身份的拉取权限后部署成功；软删除的 Foundry 账户与 RBAC 权限传播也造成过阻塞。

作者明确区分了已验证与未验证的边界：Foundry 主控、MCP 路径、OAuth 令牌获取、A2A 调用 AgentCore、结构化汇率返回及验证模式的一致判定均已确认；但冷热延迟分布、限流与令牌过期行为、多币种完整矩阵、生产级密钥轮换与可用性控制均未建立，单次冒烟结果也不构成延迟基准。代码与脱敏证据位于 xbill9/foundry-bedrock-a2a-currency。

#GitHub #开源 #A2A #MCP #微软Foundry #AmazonBedrock #AgentCore #跨云 #AI代理 #Azure #AWS
@GitHubTrendingHub

AWS、Azure、GCP 六向 A2A 互操作实测

开发者 xbill 用同一套货币兑换基准，在 AWS、Azure、GCP 三大云之间搭建了全部六个方向的 A2A 代理互操作链路，并逐一部署实测。结论先行：A2A v1.0 协议在六个方向全部互通，协议本身既不是瓶颈，也不是故障源；真正的难点集中在身份认证、依赖打包和超时策略上。

六条链路覆盖微软 Foundry、AWS Bedrock AgentCore、Google ADK 三种框架的两两组合。每次运行都采用三种模式：MCP 直连、纯 A2A 委托、以及两者并发校验。实测数据显示，A2A 单跳延迟从 1.69 秒到 25.1 秒不等，差距达 15 倍，但差异完全由远端模型和托管运行时决定，与协议无关。部署在 Cloud Run 容器上的 gemini-2.5-flash 响应最快，而两个托管代理运行时（Foundry 托管和 AgentCore Runtime）的单次调用成本高出一个数量级。

校验模式的实际开销只相当于一次远程调用，因为 MCP 与 A2A 并发执行。在正常路径上，所有跨云校验结果完全一致，准确率差异为零；校验的真正价值在于独立故障检测——当工具被篡改、数据过期或出错时，第二个云上的独立实现会明确报警。六次构建中反复出现的故障集中在 A2A 协议版本不匹配（v0.3 与 v1.0 互不兼容，且无回退协商）、依赖包版本互斥、以及默认超时设置过短（本地 10 秒足够，跨云必须放宽到 60-120 秒）。

身份认证是跨云 A2A 的最大工程。调用 Foundry 需要正确的数据面角色和 token audience；调用 AgentCore 则需处理 SigV4 签名问题，Azure 侧用自定义 JWT 授权器解决，GCP 侧采用无密钥联合身份认证，通过 STS 换取临时凭证。作者特别提醒：Google 的 audience 条件键实际对应的是 azp 声明而非 aud，必须用 oaud 固定；仅校验 audience 不等于授权，还需绑定 subject。此外，镜像打包与本地源码树不一致的问题在三次构建中出现，所有通过本地测试却在部署后暴露的缺陷都属于打包或边界问题。

作者强调，这组数据并非全面基准：六条链路中仅两条跑完完整 38 用例矩阵，两条为单次冒烟测试，两条为五次运行的中位数；token 消耗和云成本均未测量。所有相关仓库、部署脚本和原始结果已公开，欢迎有跨云 A2A 经验的开发者交流比对。

GitHub
GitHub

#GitHub #开源 #A2A #AI代理 #AWS #Azure #GCP #互操作 #MCP
@GitHubTrendingHub

GitHub 代码搜索提速：单核每秒处理超 45 GiB

GitHub 工程师近日发文，介绍其代码搜索功能的一项底层优化：通过无分支循环和字节级算术，在单核上实现了超过 45 GiB/s 的大小写折叠处理速度。

这项技术用于代码搜索的索引与匹配环节。传统的大小写转换通常依赖分支判断，而新方法通过位运算直接处理字节空间，避免了分支预测失败带来的性能损耗。对于在 GitHub 上搜索代码的开发者而言，这意味着更快的搜索响应和更高效的大规模代码库索引。

该优化已在 GitHub 代码搜索中落地，相关技术细节发布在 GitHub 官方博客。

#GitHub #开源 #代码搜索 #性能优化 #算法
@GitHubTrendingHub

OpenAI 下调 GPT-5.6 Luna 价格 80%

OpenAI 宣布 GPT-5.6 Luna 价格大幅下调。输入价格从每百万 token 1 美元降至 0.2 美元，输出从 6 美元降至 1.2 美元，降幅达 80%。同系列 Terra 版本降价 20%。

旗舰版 Sol 价格未动，但新增 Fast 模式，速度提升 2.5 倍，价格为 2 倍，智商表现不变。官方称降价源于模型自身优化，而非市场竞争或清库存。

对高频调用 API 的开发者来说，Luna 的调用成本将显著降低，适合对价格敏感的大规模推理场景。

#GitHub #开源 #OpenAI #GPT5 #API #大模型
@GitHubTrendingHub