返回首页
最新
嗨,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)
欢迎提出技术问题或批评意见——特别是来自在生产环境中运行浏览器自动化或代理系统的朋友们。
感谢您的阅读。