返回首页
最新
CloudVac 是一款本地工具,用于扫描、检查、估算成本以及清理多个配置文件和区域中未使用的 AWS 资源。<p>它读取您的 `~/.aws/credentials` 文件,并发现 EC2、RDS、Lambda、S3、CloudFormation 堆栈等服务中的资源。它会估算每个资源的月度成本,标记孤立的日志组和利用率低的项目,并提供一个依赖关系感知的删除计划,默认情况下具有干运行安全性。所有操作均在本地进行,无需遥测和外部调用。<p>我开发这个工具是因为管理多个配置文件/区域中的未使用 AWS 资源会变得昂贵且容易出错。欢迎反馈、建议和问题。<p><a href="https://github.com/realadeel/CloudVac" rel="nofollow">https://github.com/realadeel/CloudVac</a>
我是杰夫·史密斯(Jeff Smith)。我在开源人工智能领域贡献了很长时间,涉及Spark、Elixir和PyTorch生态系统。我亲眼见证了开源如何成为人们合作和共同构建人工智能的良好平台。我甚至为此写了一本书:<a href="https://www.manning.com/books/machine-learning-systems" rel="nofollow">https://www.manning.com/books/machine-learning-systems</a>,书中包含所有开源代码:<a href="https://github.com/jeffreyksmithjr/reactive-machine-learning-systems" rel="nofollow">https://github.com/jeffreyksmithjr/reactive-machine-learning...</a>
但挑战是真实存在的。AI生成的低质量代码和低水平的提交正在淹没项目。贡献量在增加,但信噪比在下降。维护者不再能够假设一个拉取请求(PR)代表了真正的投入。
Good Egg是我为此构建的一个工具。它挖掘了贡献者在GitHub生态系统中合并的PR历史,并计算出相对于您项目的信任评分。核心理念是:优秀的贡献者已经表现出良好的行为——在成熟的代码库中合并的PR、持续的贡献、跨多个项目的工作。这种记录是一个强有力的信号,并且已经存在于GitHub API中。
它的工作原理:
- 从合并的PR构建一个二分贡献图(用户 ↔ 仓库)
- 应用针对您的项目和语言生态系统的个性化图评分
- 考虑近期衰减、仓库质量(星级、语言标准化)和反作弊措施(自我贡献惩罚、每个仓库的上限)
- 将贡献者分类为高/中/低/未知/机器人
方法论文档详细介绍了整个过程:<a href="https://github.com/2ndSetAI/good-egg/blob/main/docs/methodology.md" rel="nofollow">https://github.com/2ndSetAI/good-egg/blob/main/docs/methodology.md</a>
运行方式有四种:
- GitHub Action:将其放入任何PR工作流中,并获取带有评分的评论
- CLI:good-egg score <user> --repo <owner/repo>
- Python库:await score_pr_author(login, repo_owner, repo_name, token)
- MCP服务器:将其接入Claude或其他AI助手
关于Vouch和信任圈的方法:
Mitchell Hashimoto的Vouch采取了不同的角度:维护者手动为他们信任的贡献者背书,建立信任网络。我认为这是一个有效的方法,并且看到信任圈在PyTorch等项目中运作良好,贡献者来自各个地方,包括主要的企业合作伙伴。但我也看到了一些空白,这些空白可以通过一些已经存在的数据轻松填补。Vouch要求维护者在一个独立系统中积极参与,并且存在冷启动问题。Good Egg是互补的。它是自动化的,不需要维护者额外工作,并且在任何仓库中从第一天起就可以使用。
它不做的事情:
Good Egg不会将数据发送到任何远程服务。它从GitHub API读取数据,进行本地计算,仅此而已。我并不是在构建训练集或贡献者数据库。这只是一个为社区服务的工具。
配置和扩展性:
评分参数(阈值、图权重、近期衰减、语言乘数)都可以通过YAML或环境变量进行配置。
我们计划增加更多的扩展性,特别是围绕额外数据源(例如GitLab)和方法论变体,如基于图的项目相关性以及将审查/问题活动与PR结合起来。
代码:<a href="https://github.com/2ndSetAI/good-egg" rel="nofollow">https://github.com/2ndSetAI/good-egg</a>
PyPI:pip install good-egg
文档:<a href="https://github.com/2ndSetAI/good-egg/tree/main/docs" rel="nofollow">https://github.com/2ndSetAI/good-egg/tree/main/docs</a>
希望能听到其他HN的朋友们如何走出这个低迷期。
我已经写代码近40年,几乎每天都在写,有些是为了生计,但更多是因为这让我感到无比快乐。我没有多少公开的代码库可以展示;我写代码就像艺术家在闲暇时随意涂鸦。
但最近,我感到迷失。我发现,随着新的AI大语言模型的出现,我学习新事物和编写代码的冲动完全消失了。曾经我努力学习和构建的东西,现在都可以轻松完成。很可能我的目标一直都很谦逊,而我的技能正好适合被自动化。
我想摆脱这种停滞,但我就是找不到动力去深入研究自主AI,像一个被告知要学习CAD并让机器处理细节的老派木工一样。
当然,我可以继续做我以前做的事情,因为我对金钱和名声并不感兴趣。但我想我在早期生活中有一个想法,就是内化一些微小的“套路”(模式),形成我想象中可以教给他人的见解。现在我发现我再也无法想象那个“某人”,因为我遇到的每个人都更关心AI交付最终产品,而不是经历这个过程并付出应有的努力。
抱歉啰嗦了,提前感谢大家的建议。
我写了一篇长文,分析了为什么人工智能的行为可能更多地依赖于其所处的环境,而不是模型的伦理,尤其是评估结构(如点赞、排名、即时反馈)与关系结构(如长期互动、延迟信号、纠正循环)之间的区别。<p>文章以Moltbook案例作为结构性例子,讨论了环境对齐、特权分离以及系统设计对人工智能安全的影响。<p>完整文章链接:
https://medium.com/@clover.s/ai-isnt-dangerous-putting-ai-inside-an-evaluation-structure-is-644ccd4fb2f3
我在一个音乐平台上运行AI代理时,遇到了同样的安全漏洞——没有权限继承、对嵌套调用没有成本控制、技能可以执行任意代码、出现问题时没有紧急停止开关。
Samma Suit是一个开源安全层,它为任何代理框架提供了8层保护:
- SUTRA — 带有速率限制的API网关
- DHARMA — 权限继承(父代理 → 子代理)
- SANGHA — 执行前的技能/工具审查
- KARMA — 通过子代理传播的成本控制
- SILA — 不可变的审计记录
- METTA — 加密身份签名
- BODHI — 执行隔离
- NIRVANA — 针对失控代理的紧急停止开关
该框架与LangChain、CrewAI、AutoGPT或原始API调用无关。您可以在YAML中定义策略,Samma Suit将在运行时执行这些策略。
GitHub: [https://github.com/onezeroeight/samma-suit](https://github.com/onezeroeight/samma-suit)
文档: [https://sammasuit.com](https://sammasuit.com)
今天首页上的arxiv论文(代理在30-50%的时间内违反约束)正是我们构建这个的原因——约束需要在基础设施层面强制执行,而不是留给模型。