最新

嗨，HN， 我开发了Zootopia OC Maker，这是一个小型AI工具，用于创建受迪士尼《疯狂动物城》启发的原创角色。 这个想法源于看到许多粉丝喜欢围绕《疯狂动物城》进行世界构建、同人创作、角色扮演和概念艺术，但并不一定具备绘画技能。这个工具可以让你描述一个角色（物种、职业、个性、区域、氛围），并生成一个视觉上符合《疯狂动物城》宇宙风格的原创角色。 链接： [https://aiocmaker.com/oc-maker/zootopia-oc-maker](https://aiocmaker.com/oc-maker/zootopia-oc-maker) 它的功能： - 生成《疯狂动物城》风格的动物原创角色（警察、平民、表演者、黑客、记者等） - 支持多种物种和城市角色 - 视觉风格受《疯狂动物城》1和2的启发，但角色完全原创 - 适用于同人创作、漫画、角色扮演、故事板制作，或者纯粹的创意乐趣 我为什么要开发它： 大多数AI图像工具都非常通用。我想尝试一个主题专注的原创角色生成器，它理解特定宇宙的语调、比例和个性风格，同时仍然鼓励原创角色，而不是复制现有角色。 技术说明： - 基于提示的图像生成，带有风格限制 - 关注表现力丰富的面孔、身体比例和电影灯光 - 不会复制受版权保护的角色（设计上仅限原创角色） 这仍然处于早期阶段，且非常实验性。我希望能从HN获得反馈： - 用户体验/提示流程 - 对创作工作的实用性 - 其他主题原创角色生成器的想法 欢迎提问或分享更多细节。感谢你们的关注！ — Zootopia OC Maker的开发者

大家好！<p>我很高兴与大家分享 ADK-Rust——一个基于 Rust 的 Google 代理开发工具包的生产级实现。<p>为什么选择 Rust？ 在 zavora.ai 使用 adk-python 开发 AI 代理工厂的过程中，我希望将同样强大的代理开发模式引入 Rust 生态系统，针对以下用例：<p>性能至关重要——Rust 的零成本抽象和内存安全 部署大小重要——单一二进制文件，无运行时依赖 系统级集成——嵌入式系统、边缘计算、物联网 大规模并发——Rust 的 async/await 与 tokio 功能 ADK-Rust 在可能的情况下与 Python ADK 保持 API 一致性：<p>模型无关——支持 Gemini、OpenAI、Anthropic、DeepSeek 多种代理类型——LlmAgent、SequentialAgent、ParallelAgent、LoopAgent 工具支持——内置工具（Google 搜索、代码执行）+ 自定义工具 MCP 支持——模型上下文协议集成 会话与内存——InMemorySessionService、DatabaseSessionService 流式处理——全面支持实时响应 遥测——集成 OpenTelemetry 进行追踪/度量 A2A 协议——代理间通信<p>快速示例<p>使用 adk_rust::prelude::*;<p>#[tokio::main] async fn main() -> Result<()> { let agent = LlmAgentBuilder::new() .name("my_agent") .model(GeminiModel::new("gemini-2.0-flash")?) .instruction("你是一个有帮助的助手。") .build()?;<p><pre><code> let response = agent.run("你好！").await?; println!("{}", response); Ok(())</code></pre> }<p>链接 Crates.io: <a href="https://crates.io/crates/adk-rust" rel="nofollow">https://crates.io/crates/adk-rust</a> 文档: <a href="https://docs.rs/adk-rust" rel="nofollow">https://docs.rs/adk-rust</a> 网站: <a href="https://adk-rust.com/" rel="nofollow">https://adk-rust.com/</a> GitHub: <a href="https://github.com/zavora-ai/adk-rust" rel="nofollow">https://github.com/zavora-ai/adk-rust</a> 寻求反馈 我很想听听社区的意见：<p>你们会优先考虑哪些代理功能？ 有没有兴趣参与贡献或测试？ 在哪些用例中 Rust 实现会有价值？ 这是一个独立的社区项目，并未与 Google 官方关联，但旨在与 ADK 生态系统兼容。<p>感谢阅读！

嗨，HN， 我想分享一个我们已经开发了一段时间的开源项目：**Browser4**。 这个项目的动机源于一个反复出现的挫折：大多数浏览器自动化工具（如 Playwright、Selenium、Puppeteer）在处理**人类编写的脚本**时表现出色，但在作为**AI代理的核心执行层**或在高并发情况下使用时，开始出现一些摩擦。 因此，我们没有选择“在 Playwright 上再做一个封装”，而是尝试了一个不同的方向：**设计一个将 AI 代理视为第一公民的浏览器引擎**。 ### Browser4 是什么 Browser4 是一个基于**原生 Chrome DevTools 协议（CDP）**构建的浏览器自动化引擎，重点关注： * **协程安全的并发**（旨在并行运行多个浏览器会话） * **面向代理的 API**（导航、交互、提取作为可组合的操作） * **混合提取**：机器学习代理驱动的提取 + 大语言模型提取 + 结构化选择器 + 类 SQL 的 DOM 查询语言（X-SQL） * **低级控制**，没有 Playwright 风格的抽象开销 它是用**Kotlin/JVM**编写的，主要是因为我们需要可预测的并发行为和在负载下的长时间稳定性。 该项目完全开源（Apache 2.0）。 ### 它**不是** * 它不是一个可以直接替代 Playwright 的工具。 * 它不是一个无代码的 RPA 工具。 * 它不是“LLM 魔法”——LLM 位于浏览器引擎的**外部**。 Browser4 有意保持与浏览器执行层的紧密联系，将规划和推理留给外部代理循环。 ### 我们正在测试的当前用例 * 大规模网页数据提取 * 代理工作流（搜索 → 导航 → 提取 → 总结） * 价格/内容监控，频繁回访 * 高并发爬虫，其中浏览器启动和上下文切换是瓶颈 在单台机器上，我们可以维持**非常高的每日页面访问量**，尽管我们仍在验证不同工作负载下的基准。 ### 需要开放的问题（我很想听听反馈） * 对于代理系统，完全绕过 Playwright 并更接近 CDP 是否合理？ * 在将 LLM 与浏览器自动化结合时，您看到的最大痛点是什么？ * JVM 在这里是一个合理的选择吗，还是尽管存在并发限制，Python 仍然是更好的权衡？ * 在为 AI 代理构建的浏览器引擎中，您希望有哪些抽象？ ### 链接 * GitHub: [https://github.com/platonai/browser4](https://github.com/platonai/browser4) * 网站（简要概述）：[https://browser4.io](https://browser4.io) 欢迎提出技术问题或批评意见——特别是来自在生产环境中运行浏览器自动化或代理系统的朋友们。 感谢您的阅读。