24小时热榜

# 什么是 pyrig？<p>pyrig 是一个工具包，可以为您的项目“搭建框架”。它通过一条命令搭建并初始化一个完整、配置完毕、已安装且可工作的 Python 项目，并通过自动化配置管理、命令行界面生成、测试基础设施等流程，使开发和维护过程更加顺畅高效。<p># 系统要求<p>* Python 3.12+ * Git * uv<p># 快速开始<p><pre><code> uv init my-project --python 3.12 cd my-project uv add pyrig --dev uv run pyrig init </code></pre> 请参阅 [入门指南](<a href="https://Winipedia.github.io/pyrig/getting-started" rel="nofollow">https://Winipedia.github.io/pyrig/getting-started</a>)，获取详细的设置说明，以便从一开始就与 GitHub 和 CI/CD 完全集成。<p># 功能<p># [项目搭建与初始化](<a href="https://Winipedia.github.io/pyrig/scaffolding" rel="nofollow">https://Winipedia.github.io/pyrig/scaffolding</a>)<p>`pyrig init` 一条命令即可生成一个开箱即用的完整项目。这包括现代 Python 项目所需的所有内容：<p>* 标准化的目录结构 * 完全配置的开发工具（代码检查工具、格式化工具、类型检查器、测试框架、Git 钩子等） * 包含 GitHub Actions 的端到端 CI/CD 流水线和集成的代码库保护 * 完整且可工作的命令行界面 * 还有更多...<p># [文件与配置管理](<a href="https://Winipedia.github.io/pyrig/config-files" rel="nofollow">https://Winipedia.github.io/pyrig/config-files</a>)<p>每个生成的文件都有一个 Python 类作为支持，能够自动验证和合并。通过子类化可以覆盖任何配置，或者定义全新的配置文件——pyrig 会为您发现并管理它们。运行 `pyrig sync` 可以一次性创建或更新所有配置文件。运行 `pyrig mk subcls` 可以为覆盖特定文件生成一个子类。<p># [自动命令行界面](<a href="https://Winipedia.github.io/pyrig/cli" rel="nofollow">https://Winipedia.github.io/pyrig/cli</a>)<p>`pyrig init` 为您的项目设置一个立即可用的命令行界面。通过运行 `pyrig mk cmd <name>` 生成并添加新命令。包括一个自动版本命令，可以显示您项目的版本。运行 `my-project version` 来查看其效果。<p># [镜像测试生成与维护](<a href="https://Winipedia.github.io/pyrig/mirror-tests" rel="nofollow">https://Winipedia.github.io/pyrig/mirror-tests</a>)<p>使用 `pyrig sync` 生成测试骨架。这将为所有源模块生成测试骨架，并在您的项目发展过程中自动更新它们。<p># [多包继承与扩展架构](<a href="https://Winipedia.github.io/pyrig/architecture" rel="nofollow">https://Winipedia.github.io/pyrig/architecture</a>)<p>覆盖和自定义任何行为以满足您项目的需求。pyrig 的类设计用于继承和组合，允许您通过子类化和简单覆盖方法来创建自定义配置、工具等。pyrig 会自动发现并使用您的自定义类，无需额外配置。运行 `pyrig mk subcls` 为任何 pyrig 类生成一个子类。<p># [CI/CD 与代码库保护](<a href="https://Winipedia.github.io/pyrig/ci-cd" rel="nofollow">https://Winipedia.github.io/pyrig/ci-cd</a>)<p>Pyrig 生成 GitHub Actions 工作流以实现 CI/CD，自动测试和发布您的代码。它们还配置并应用代码库保护设置和保护规则。初始化后将代码推送到 GitHub，查看其效果。<p># 命令<p>运行 `pyrig --help` 查看所有可用命令及其用法。运行 `pyrig <command> --help` 获取有关特定命令及其用法的更多信息。运行 `my-project --help` 查看为您的项目自动生成的命令行界面。<p># 文档<p>|[*完整文档*](<a href="https://Winipedia.github.io/pyrig" rel="nofollow">https://Winipedia.github.io/pyrig</a>)|手动编写的文档| |:-|:-| |[*代码维基*](<a href="https://codewiki.google/github.com/winipedia/pyrig" rel="nofollow">https://codewiki.google/github.com/winipedia/pyrig</a>)|AI 生成的文档| |[*教程*](<a href="https://www.youtube.com/@Winipedia-py/playlists" rel="nofollow">https://www.youtube.com/@Winipedia-py/playlists</a>)|pyrig 的 YouTube 教程|

嗨，HN！<p>我同时运行了几个Claude Code会话，不停地切换窗口，结果发现其中一个会话在权限提示上停留了十分钟。我喜欢一个硬件小工具（叫做SidePulse.io），所以在等待我的货物到达之前，我先自己做了一个软件版本 :D<p>希望你们会喜欢，并觉得它和我一样有用！

你好，社区！<p>我在这里分享一个我独立从零开始构建的编码代理，使用了代理工程技术。它是用Go语言编写的，功能齐全，具备你在日常工作中所期待的有用代理特性，界面简洁明了。<p>我将它命名为Keen Code。代码库链接在这里：<a href="https://github.com/mochow13/keen-code" rel="nofollow">https://github.com/mochow13/keen-code</a><p>尽管它最初是一个实验，但现在已经成为一个成熟的编码代理，可以用于实际的软件工程工作。它支持多个提供者、技能、MCP（多通道处理）、通过子代理进行多代理编排、自动压缩等功能。<p>我自己已经在实际的生产级工作中使用它，同时也用于自身的开发。<p>值得注意的是，我在这个编码代理上实现了两个独立的想法：<p>1. 回合记忆<p>在多轮对话中，工具输出会被移除，仅保留工具调用的痕迹。在单个代理循环中，代理可以看到完整的工具结果，但在下一轮中，它将不再看到工具结果。<p>这种方法的最大好处是，许多在后续轮次中不需要的工具结果不会占用上下文。因此，Keen Code在多轮对话中的上下文窗口填充速度比其他代理慢得多。这就是为什么你会经常看到上下文窗口在新代理轮次开始时从20%下降到1%。<p>当然，这种方法有其优缺点。如果代理需要先前调用的工具结果，它将无法获得。但我的想法是，像读取、bash、web_fetch这样的工具调用是便宜的。你需要参考之前读取的某个文件吗？再读一次。实际上，Claude Code或Codex经常重新读取文件，即使它之前已经读取过同一个文件。<p>我计划在这一领域投入更多的精力。我还有一些额外的想法需要探索，并可能进一步优化这种方法。<p>如果你想了解更多，可以阅读这里：<a href="https://mochow13.github.io/keen-code/docs/turn-memory.html" rel="nofollow">https://mochow13.github.io/keen-code/docs/turn-memory.html</a><p>2. 技能驱动的MCP<p>我实现的另一个想法是技能驱动的MCP。目标与Anthropic在工具搜索工具中所做的类似：优化上下文。<p>在这个想法中，每个MCP服务器接收一个技能。但这个技能并不是典型的“MCP服务器使用指导”技能，而是由Keen生成的。详细信息在这里：<a href="https://mochow13.github.io/keen-code/docs/mcp-skills.html" rel="nofollow">https://mochow13.github.io/keen-code/docs/mcp-skills.html</a><p>其主要优点是，默认情况下没有服务器完全预加载工具模式。代理仅接收服务器的技能前言。如果需要某个服务器，代理会加载完整的技能文件，其中列出了工具及其描述。然后，代理会读取特定工具的模式文件，以便调用该工具。<p>缺点是每次MCP调用都需要文件读取操作。但一切都在发现时本地保存，所以这完全没问题。<p>---<p>除了上述两个想法外，我还在探索和尝试其他知名的上下文优化想法，如哈希行编辑。<p>如果你对以上想法感兴趣，请务必查看！这里是CLI使用指南：<a href="https://mochow13.github.io/keen-code/docs/cli-usage.html" rel="nofollow">https://mochow13.github.io/keen-code/docs/cli-usage.html</a><p>由于该项目是开源的，欢迎提出问题和贡献！

在实施一个大型高性能服务的过程中，为了保持上下文简洁（主要是为了人类理解），我将规格整理成了mermaid图表。在与人类沟通时，这些图表易于理解和记忆。但当我要求代理实现图表中的内容时，大多数情况下它们都失败了。 因此，我得出结论：代理在编写mermaid图表方面表现良好，但在读取图表时却不够出色。 我开发了graph2agent，旨在以确定性的方式（不依赖推理 :)）将mermaid图表转换为代理易于理解的丰富文本。例如： [示例链接](https://github.com/graph2agent/examples/blob/main/examples/markdown/five-families.md?plain=1) 这使得我们在任何类型的图表中减少了50%的错误率，而在序列图中则减少了80%的错误率。同时，输入的token数量平均增加了8%（这是预期的），但推理token的数量几乎下降了50%。 您可以将其与MCP结合使用，这样代理可以调用任何mermaid图表，也可以将其放入预提交作业中，在每个PR上运行，以确保所有图表都能被代理处理！ 希望您喜欢这个工具！欢迎分享您的想法！