开发者工具箱｜编程·开发工具·资源

用 React Flow 画布直接跑 Agent

React Flow 不只是画工作流图的工具，也可以直接作为运行中 agent 系统的控制平面。作者在 IntegrateX 上把画布当作运行时直接执行，而不是先画图再翻译成另一套配置。

核心思路：把节点重新定义为能力（trigger、agent、tool、output），把边定义为类型化契约——一个能力的输出是下一个能力的合法输入。PM 拖出来的图，就是运行时执行的规格，不需要 shadow YAML 或并行 DSL。

类型化端口是关键：给每个 handle 标上类型（文档流、工具结果、终端 done），用户在画图时就能拒绝不兼容的连接，整类运行时 bug 直接消失。代码示例：isValidConnection 检查源端口类型是否在目标端口的兼容列表里。

分离渲染图与运行图：React Flow 状态只负责渲染模型（位置、选中、缩放、视觉边），执行器消费的是派生出的运行图（能力与类型化连线）。作者称之为 Trinity Architecture：Presentation 负责渲染与派发事件，Reactive State/Orchestration 持有数据源与乐观更新，Data/Serialization Adapter 把内存状态编译成精简的线上载荷。

在 IntegrateX 上，Serialization Adapter 在持久化前剥离 React Flow 元数据，payload 体积削减 94%，消除了同步卡顿与载荷膨胀。边界规则：UI 不格式化 DB schema，adapter 不直接碰 UI 状态，只通过 orchestrator 通信。

可视化、类型化的图对 PM 可读、对支持可改、对工程师可实时调试。作者强调，整个团队都能读懂和修改的架构，比只有作者自己看得懂的聪明方案更有价值。

🔗 原文：点击查看

序列化边界：一次架构决策让工作流画布负载缩减 94%

IntegrateX 是一款基于节点的自动化工作流画布，支持拖拽节点、连线并运行流程。作者在构建早期面临一个关键决策：用户保存工作流时，到底该保存什么？最直接的做法是把 React Flow 节点 JSON.stringify 后存入数据库，但这种方式埋下了隐患。

React Flow 画布上的每个节点都携带位置、尺寸、选中状态、样式、z-index 等大量渲染器状态。当工作流增长到数百个节点时，90% 以上的存储和传输字节都是客户端可以免费重建的视图状态，导致保存变慢、首字节时间膨胀、存储成本攀升。

解决方案是架构层面的：在 UI 模型和领域模型之间划出硬边界，构建一个无损、感知 schema 的序列化适配器。每个节点类型映射为紧凑结构体，只保留类型、逻辑配置、连接关系以及默认值无法推导的增量；加载时再由适配器结合 schema 重新水合完整的 React Flow 对象。往返无损，负载减少 94%，画布状态机（Zustand）完全无需感知持久化层的存在。

这 94% 的缩减换来的是即时保存与加载体验、稳定的领域 schema（使分析、版本化、服务端执行成为可能），以及 UI 自由演进——界面可以随意重新设计节点，适配器吸收变化，旧存档依然能正常加载。

这一模式适用于所有富客户端产品：文档编辑器、BI 仪表盘构建器、设计工具、带自定义视图的 CRM。如果持久化层镜像渲染层，增长到一定规模就会撞上同样的墙。排查只需一个下午：抽样一份持久化负载，标出所有客户端可重建的字段，比例通常触目惊心。

🔗 原文：点击查看

TokenPrint：3D可视化调试LLM推理

TokenPrint 是一个开源的 3D 可视化调试环境，面向 Transformer 和 LLM 推理。它把 token 在模型中的完整旅程——从 token ID 到 embedding，经过各层归一化、注意力、投影、非线性变换和残差连接，直到最终 logits——以 3D 计算图的形式呈现，让内部计算真正可见、可检查。

逐层检查：可查看 token embeddings、位置信息、RMSNorm、Q/K/V 投影、Grouped-Query Attention、RoPE、注意力分数、softmax、加权值聚合、输出投影、SwiGLU MLP、残差流、logits 与预测。
组件检查：选中任意组件可查看功能说明、数学方程、输入输出维度、参数数量、关联张量路径及数据来源。
数据来源分类：REAL（直接来自模型/运行时）、DERIVED（由真实模型信息计算）、CONCEPTUAL（概念性教育表示）、SIMULATION（模拟行为），避免可视化凭空捏造模型内部。
张量检查：例如 model.layers.3.self_attn.v_proj.weight 可显示 shape 128×896、dtype float32、约 114.7K 参数、层 3、运行时 hf_local。
实验方向：注意力检查、激活分析、残差流分析、张量检查、层/头实验、消融、激活修补、轨迹回放、模型比较。

TokenPrint 开源，欢迎贡献。未来计划支持更广泛的 Hugging Face 模型、远程推理、可共享的 transformer 轨迹等，目标是让 LLM 的内部行为可检查，而非黑盒。

GitHub: GitHub

🔗 原文：点击查看

#开发者 #工具 #TokenPrint #LLM #Transformer #3D可视化 #调试 #开源

AI财务代理Sable：模型无权动钱

Sable 是一个本地优先的 AI 财务代理应用，基于 React Native 构建，没有任何云后端。所有债务、支付、余额数据都存储在设备端 SQLite 中，AI 层需要上下文时直接查询本地数据库，网络只传输蒸馏后的最小上下文，绝不包含账本本身。隐私在这里是拓扑结构而非政策——没有服务器，就没有可被攻破的服务器。

核心信任边界是“模型提议、人类确认”。Sable 使用 OpenAI 函数调用，但每次调用都是干跑：模型决定“记录一笔 ₹5,000 的汽车贷款还款”时，该意图渲染为 UI 中的“审查并确认”卡片，只有人类点击确认后数据库才会变更。幻觉的最坏结果是产生一张可忽略的卡片，永远不会在账本里写入错误数字。

生产级设计：
• 串行写入队列逐个处理 SQLite 变更，消除写锁竞争；每日本地 RAG 任务读取设备端账本，向锁屏推送主动 Morning Briefing（支出节奏、即将到期的义务、异常）；默认离线优先，飞行模式下完全可用，AI 层是增强而非依赖。这套 propose/confirm 边界和本地上下文模式可直接迁移到医疗记录
• 法律文件
• 内部财务等企业领域——数据需要 AI 杠杆，但不能容忍 AI 权威

🔗 原文：点击查看

#开发者 #工具 #Sable #AI代理 #本地优先 #SQLite #ReactNative #OpenAI #RAG

LinkDigest：一键把小红书内容转成可读文本

小红书、抖音、TikTok 等短视频平台的帖子往往只在页面中以图片或视频形式呈现，普通 HTTP 请求无法直接获取文本。LinkDigest 通过两步流程：先抓取页面的 state blob，再解析其中的 imageList 与文本信息，生成带时间戳、OCR 文字、图片描述、标题与元数据的 Markdown 或 JSON。一次请求即可得到完整的文字稿，支持 17 张图的帖子生成 381 条文本片段、13 条关键信息，耗时约 119 秒。服务提供 REST API、MCP 接口和 Web 控制台，免费提供三次摘要。

该工具不支持 Bilibili（HTTP 412）、Instagram（需登录）和 Facebook。若某部分内容无法读取，返回结果会标记为 degraded；完全无法读取则返回空结果且不计费。

GitHub GitHub

#开发者 #工具 #LinkDigest #小红书 #短视频抓取

🔗 原文：点击查看

pdlc‑skills：让进度、影响与质量可视化

pdlc‑skills 通过三款命令行工具把项目状态集中在同一份 state 文件里，实时回答三大问题：

- 现在在哪里？ statusline 与 /pdlc-status 显示每个功能的阶段、检查结果和停留时长，自动标记阻塞点。
- 变更会触及哪些？ /pdlc-relate 生成依赖图，按 extends、depends_on、supersedes 等关系展示直接与间接影响。
- 本周期表现如何？ /pdlc-retro 汇总过去 30 天的交付、检查通过率、阶段平均时长等指标，帮助评估流程健康。

所有工具只读取 docs/.pdlc-state/，不解析代码或文档，保持数据一致性与可追溯性。安装脚本：

```
curl -fsSL | bash -s -- --global
```

GitHub 仓库： GitHub

🔗 原文：点击查看

#开发者 #工具 #pdlc #AI #软件工程 #质量管理 #CLI #DevOps #GitHub #Nodejs

AICOM 与 AIMarket：从工厂到市场的完整 AI 开发链

AICOM 是一个专注于把简短需求转化为可部署 Web 产品的工厂。团队通过分析、设计、编码、测试、部署的 13 个人工智能与软件工程角色，完成从“一句话”到可预览页面的全流程。首次使用无需登录，页面直接生成，且通过质量门控保证已完成的功能不含占位符或 TODO。

AIMarket 则是 AICOM 产出的产品在其中被发现、调用并获得签名收据的经济体。它提供 17 个数学 oracle、一个可交互的 “洞穴” 以及 HEPHAESTUS 链路估算工作室，让其他代理在 3D 视图中直接调用能力，并可验证返回结果的真实性。

两者共享 MIT 堆栈与实时接口，核心流程为：构建 → 发现 → 调用 → 验证。所有操作均可自托管，使用者可自行管理模型密钥与数据。

访问工厂：magic‑ai‑factory.com
访问市场：oracles.modelmarket.dev / forge.modelmarket.dev
源码：github.com/alexar76/aicom

🔗 原文：点击查看

#开发者 #工具 #AICOM #AIMarket #AI工厂 #AI市场 #数学Oracle #链路估算 #自托管

K8s v1.37 原生直方图转正Beta

Kubernetes v1.37 将原生直方图（Native Histograms）支持升级为 Beta，并默认启用。该特性此前在 v1.36 以 Alpha 引入（KEP-5808），通过采用 Prometheus 原生直方图，Kubernetes 组件能以更高精度暴露延迟与耗时指标，同时显著降低遥测存储与抓取开销。

经典直方图要求指标作者预定义静态累积桶边界（le 标签），存在三大问题：桶边界靠猜，延迟分布变化后失去可见性；每个桶边界单独导出为一条时间序列，推高基数与 TSDB 存储成本；histogram_quantile() 依赖静态桶间线性插值，桶跨度大时分位数误差明显。

原生直方图以动态指数桶替代静态用户定义桶，单条时间序列内包含正负跨度、零阈值与指数缩放因子。优势包括：自动适配纳秒到小时级任意值域；时间序列数量最多减少 90%；默认设置下分位数计算最坏相对误差约 5%。

实现位于共享指标子系统 k8s.io/component-base/metrics，采用双暴露机制：经典桶与原生跨度同时输出，现有 Prometheus、仪表盘与告警规则无需改动。默认指数配置为 BucketFactor 1.1、MaxBucketNumber 160。kube-apiserver、kube-scheduler、kubelet、kube-controller-manager 与 kube-proxy 均自动继承支持。

抓取配置按 Prometheus 版本区分：3.0+ 推荐在 scrape_configs 中设置 scrape_native_histograms: true 与 always_scrape_classic_histograms: true；2.40–2.x 需以 --enable-feature=native-histograms 全局启用。迁移建议分四步：双格式采集、查询迁移至原生直方图语法、在预发/生产验证、确认无误后关闭经典格式抓取，时间序列数量可减少约 90%。回滚灵活，采集端设 scrape_native_histograms: false 即可，组件端可用 --feature-gates=NativeHistograms=false 关闭。

原生直方图正朝 GA 推进，SIG Instrumentation 将持续评估生态就绪度与性能表现，并规划经典静态桶的长期弃用路径。

🔗 原文：点击查看

#开发者 #工具 #Kubernetes #Prometheus #可观测性 #SIGInstrumentation #KEP5808 #监控 #云原生
@DevToolboxHub

Postgres角色限制可被会话自身绕过

给 AI 代理数据库角色设置 statement_timeout 和只读事务，是常见的加固手段。但实测表明，这些限制只约束会话的初始状态，代理在自己的会话里可以随时解除。

用 SET 命令即可当场关闭限制，且不会留下 ALTER 痕迹。更隐蔽的是通过连接串或 PGOPTIONS 环境变量传入 -c 参数，source 显示为 client，优先级高于角色级 user 设置，日志里连 SET 都看不到。

PostgreSQL 15 引入的 GRANT SET ON PARAMETER 也无法补救：USERSET 参数本就允许所有角色修改，REVOKE 不会写入 pg_parameter_acl，实际不生效。真正有效的约束是 CONNECTION LIMIT、对象权限和 pg_terminate_backend，这三者无法从会话内部绕过。

测试基于 PostgreSQL 18.6，事务超时对比在 17.11 和 16.15 上完成。给代理数据库授权时，别把超时和只读设置当作安全边界。

🔗 原文：postgr.es/p/9ul

#开发者 #工具 #PostgreSQL #数据库安全 #AI代理 #权限控制 #USERSET
@DevToolboxHub

Rust 服务端驱动 UI 新方案

WebForms Core 是 Elanat 推出的服务端编排 UI 技术，现已提供 Rust 实现。webformscore 2.1.0 crate 已发布，支持与 Actix Web 等 Rust Web 框架配合使用。核心思路是服务端生成描述 HTML 变更的命令，浏览器端由 WebFormsJS 执行这些命令，Rust 应用不直接操作 DOM。

架构链路：Rust Server → WebForms Class → WebForms Core Commands → WebFormsJS → HTML DOM

安装 Rust 端：cargo add webformscore，或手动在 Cargo.toml 添加 webformscore = "2.1.0"

浏览器端 WebFormsJS 独立于 Rust 后端，可通过 npm install webformsjs 安装，或从官方 GitHub 仓库获取源码，也可在 Elanat 网站下载对应版本

示例：用 Actix Web + Tera + webformscore 构建学生成绩表，点击按钮后服务端生成着色命令，按分数区间给表格单元格上色，无需返回完整 HTML，也无需自定义 JS 事件处理

服务端负责交互逻辑，浏览器端负责 DOM 执行，HTML 保持普通文档即可。这为 Rust 开发者提供了一种不需要单独前端项目的服务端驱动 UI 方案。

GitHub

🔗 原文：点击查看

#开发者 #工具 #Rust #ActixWeb #WebForms #服务端驱动UI #前端开发
@DevToolboxHub