从不触碰目标的安全扫描器

客户要求为销售漏斗建一个“快速安全检查”工具，输入域名返回安全评分。主动扫描存在法律风险：在部分司法辖区，扫描非自有系统可能违法。于是工具必须完全被动——不向目标发送任何数据包，所有数据来自第三方已缓存的扫描结果。

四个数据源覆盖了基础安全评估：SSL Labs API提供证书、协议和密码套件信息；Shodan和Censys扫描整个公网IPv4空间并缓存开放端口与服务；crt.sh查询证书透明度日志，暴露被遗忘的子域名；CIRCL CVE API关联已识别软件版本的已知漏洞。整个管线设计假设与目标零交互，仅依赖正常浏览器请求已完成的数据。

这是一个比主动扫描更窄的工具，深度不及真实渗透测试，但它的优势是——任何人可以对任何域名使用，无需法律团队介入。对于销售漏斗场景，这是更实用的权衡。

#开发者 #工具 #安全扫描 #被动扫描 #SSLLabs #Shodan #Censys #CIRCL #CVE
@DevToolboxHub

EveAgents 开源 AI 智能体集合发布

基于 Eve 框架的开源 AI 智能体集合 EveAgents 现已发布。每个智能体有明确的角色、领域专用指令、安全护栏和可选集成，MIT 许可，可自由修改和部署。支持本地运行或一键部署到 Railway。以下是套装内 10 个智能体的快速概览和部署流程。

EveAgents 由 Zoltán Szőgyényi 构建，旨在提供聚焦特定任务的 AI 智能体，而非通用助手。每个智能体包含 instructions.md（角色与工作流）、agent.ts（模型配置）、skills/（领域技能）、examples/（测试提示）等独立项目文件，团队可自行审查和定制。
部署到 Railway 最快：从 SEO Growth Analyst 入手，进入其页面选择独立版本，创建 EveAgents API 密钥，打开 Railway 模板创建项目，配置环境变量（EVE_AGENT_SLUG, EVEAGENTS_API_KEY, EVE_MODEL 等），部署并验证健康检查 /eve/v1/health。完成后保持 basic-auth 凭证以防止未授权使用。
10 个开源智能体及 Railway slug：
1. SEO Growth Analyst (seo-growth-analyst) – 基于证据的搜索机会分析和内容建议，可选集成 Similarweb、Local Falcon、Webflow、Notion、Slack、Teams 等。
2. Incident Response Commander (incident-response-commander) – 事故调查与响应协调，集成 Datadog、Sentry、Honeycomb、Linear、Notion、Slack、Teams、Discord。
3. API Reliability Investigator (api-reliability-investigator) – API 可靠性诊断，连接请求、日志、追踪和错误，集成 Postman、Datadog、Honeycomb、Sentry、GitHub、Slack、Teams。
4. Product Feedback Synthesizer (product-feedback-synthesizer) – 定性反馈与产品信号合成，集成 Notion、Linear、PostHog、Mixpanel、Slack、Teams。
5. Feature Adoption Analyst (feature-adoption-analyst) – 功能采用与流失分析，集成 PostHog、Mixpanel、ClickHouse、Notion、Slack、Teams。
6. Customer Support Triage Agent (customer-support-triage-agent) – 客户支持工单分类与草拟回复，集成 Slack、Teams、Telegram、Twilio、Notion、Airtable、Linear。
7. Customer Onboarding Concierge (customer-onboarding-concierge) – 引导式客户 onboarding，集成 Notion、Airtable、Todoist、Mem0、Slack、Teams、Telegram。
8. Revenue Operations Analyst (revenue-operations-analyst) – 收入运营数据核对与报告，集成 Stripe、Brex、Embat、Airtable、Slack、Teams。
9. Meeting Action Planner (meeting-action-planner) – 会议笔记转决策与行动计划，无需集成，可直接粘贴转录。
10. Nonprofit Grant Researcher (nonprofit-grant-researcher) – 非营利机构资助寻找与评估，集成 Candid、Notion、Airtable、Slack、Teams。
所有智能体也可本地运行：npx @bergside/eveagents install <slug>，然后使用 npx eve@latest 启动。列表查询：npx @bergside/eveagents list。

EveAgents 的设计初衷是让智能体行为可审查、可定制。通过开源和模块化架构，团队可以在每个工作流中独立测试和改进。

#开发者 #工具 #EveAgents #AI #开源 #Vercel #Railway #SEOGrowthAnalyst #IncidentResponse #API
@DevToolboxHub

Insight Compiler：改问题而非给答案

向 AI 助手提开放型问题，得到的回答往往合理但泛泛——缩小目标、差异化、做 MVP、聊用户。这些都对，但不会真正推动你向前。Insight Compiler 是一个 Agent Skill，把泛泛答案当作起点而非终点：它先明确写出普通回答，再用后续步骤爬出那个答案的局限。

技能每次运行七步：意图发现（分离表面问题与真实目标）→ 普通答案基线（写出正常 AI 会怎么答）→ 领域视角（借助军事、城市设计、游戏等陌生领域审视问题）→ 发现算子（反转、换位、缩放，找无人注意的缺口）→ 提示库（交叉领域与算子产出密集线索）→ 策略候选（2-3 个方向，每个回溯到具体线索）→ 诚实评估 + 验证分支（不制造平局，预先承诺每个测试结果对应什么行动）。第 2 步是关键——未写出的普通答案是模型悄悄躺进去的天花板，写下来就是可以蹬离的地板。

实际演示：作者问“发布的技能仓库无人访问怎么办”，普通助手回答“改善 README、加 GIF、发到 X 和 Reddit”。Insight Compiler 第一步就拒绝了原问题，提炼为“目标用户在哪第一次接触足够价值以触发思维变化”，并指出“低访问=解释不够”这个前提混淆了发现/分发瓶颈与理解瓶颈。它给出的方案之一是先确定为谁做、产出一个完整示例打动一个人、把输出本身当作内容分发，而不是优化仓库页面。三个候选诚实评级后，最终建议是“先做无聊的 README 改进，因为它几乎零成本，但这是必要条件而非充分条件”。完整对话及两种答案对照都在仓库里。

安装方式：Agent Skill 本质是一个含 SKILL.md 的目录。对 Claude Code：
```
git clone GitHub
mkdir -p ~/.claude/skills
cp -r insight-compiler/InsightCompiler ~/.claude/skills/
```
重启后确认加载。还有一个 InsightCompilerPersonal 版本，在本地配置文件中只记录工作习惯，不构建信息茧房，安装二选一。不适合需要快速事实回答、代码或短决策的场景；其市场缺口判断是推理假设，需自行验证。

仓库：https://github.com/snc2work/insight-compiler (MIT)

#开发者 #工具 #InsightCompiler #Claude #AgentSkill #AI #开源
@DevToolboxHub

Standard Ten：用统一标准重构AI代码生成

AI生成代码的速度很快，但缺乏统一标准会导致架构不一致。Adi Cohen 提出 Standard Ten，主张将全部软件重写为一套统一标准，让人类和AI每次都生成相同的最佳实践结构。

Standard Ten 的核心原则：每个操作接收并返回一个规范“Thing”；程序按嵌套结构组装；所有输出从一个规范种子派生；无手写应用代码；无 OOP；无应用控制流（用事件、路由、map/fold代替）；所有目标使用统一事件机 UEM-16；外部效应通过命名边界；失败必须记录工单；相同输入产生相同输出；测试从同一源生成并完全验证。

开发者只需写一种受约束的 Python 语言，系统生成 UEM 字节码、WebAssembly、原生码等。UEM-16 是芯片无关的虚拟机器，指令集包括 LOAD、ROUTE、MAP、FOLD 等。GUI 和浏览器也通过同一接口协议适配。

已演示成果：基于 Python 的内核、完整小应用生成器、两个独立领域（文本统计和发票汇总）的零手动修正实现、UEM-16 字节码在 Python 和 C99 宿主上跨平台等价执行、全面的测试套件（法则、效果、变异、性能等）。

该项目不宣称支持所有芯片，ARM64、RISC-V 等需在物理硬件上运行无误后才声明。AI 应当像确定性数学系统一样生成软件：从一小套规范词汇出发，在明确法则下产生可复现结果和完整验证。

GitHub

#开发者 #工具 #StandardTen #UEM16 #AI代码生成 #确定性
@DevToolboxHub

基于TOFU的无头AI Agent认证方案

构建AI Agent时，一开始只需一个Personal Access Token（PAT），但随着接入Slack、Notion、Linear等服务，长期凭证散落在.env、CI/CD、K8s Secret和基础设施中，安全隐患和运维负担随之攀升。Passkey提出一种借鉴SSH「Trust On First Use（TOFU）」的授权模型，让Agent无需任何长期凭证即可安全访问外部服务。

传统OAuth依赖人类在浏览器中点击「允许」，但无头Agent没有交互界面。开发者通常退而求其次：PAT扩展快但留下技术债；自定义OAuth需为每项服务处理回调、加密、刷新，认证层比产品本身还庞大；Secret Manager仅解决存储，不解决授权；Service Account让所有Agent共享同一身份，单点泄露影响全局。

Passkey的目标是：Agent永不接触长期凭证；人类仅需批准一次新Agent；每次操作可归因到特定Agent；撤销一个Agent不影响其他部署；现有框架无需改动。方案来自SSH的TOFU模型：首次连接时检验主机指纹，用户确认后记住指纹，之后自动连接。类比到Agent，首次请求时网关暂停请求，Owner收到审批通知，通过后存储指纹，后续请求自动放行。

具体流程：开发者一次性OAuth连接服务，凭证留在网关内。Agent启动时获得一个Passkey URL，请求网关获取GitHub等工具时，网关检查指纹。未知指纹触发人工审批，通过后交换一个短令牌（非刷新令牌、PAT或client secret），Agent直接调用上游API。指纹由运行时特征派生，每个Agent拥有唯一身份，请求可归因、可审计，撤销指纹即可封锁该Agent，无需轮换凭证或重新部署。

集成方式：通过MCP协议，任何兼容MCP的框架（LangChain、CrewAI、Strands、Bedrock AgentCore）无需改动，Agent自动看到工具列表如github_list_issues等。网关使用令牌交换而非代理所有请求，降低延迟、避免瓶颈、兼容现有MCP工具。

其他设计：
• 连接URL使用轮换slug
• 支持动态客户注册（减少限流竞争）
• 原生MCP

该模型尤其适合接入多个SaaS平台、需要审计和归因、安全团队禁止PAT散落的场景。安装本地代理只需执行 npx passkey-mcp，目前内置19个集成（GitHub、Slack、Jira、Confluence、Notion、Stripe、Salesforce、HubSpot、Linear等）。核心问题已验证：无需长期凭证，且不降低开发体验。

#开发者 #工具 #AI #Agent #TOFU #MCP #Passkey #CICD
@DevToolboxHub

威胁建模：健康仪表盘的同意边界测试

健康连接器即使标记为“只读”也可能跨越权限边界。真正的危险并非攻击者利用，而是用户以为访问结束后仍在进行的合法后台刷新。安全不变量应比“令牌有效”更强：每次读取必须获得当前、基于特定目的的同意。OpenAI 2026年7月23日宣布在美国向18岁以上用户推出Health in ChatGPT，支持医疗记录和Apple Health，数据不用于训练模型或定向广告。

资产模型包含四类：连接凭证、导入记录、派生仪表盘视图和审计证据。同意服务需与导入工作器和对话检索分离。关键设计决策：提供商令牌单独不能证明当前同意，工作器必须提交授予标识、请求目的、数据类别和操作时间。策略决策应记录到安全日志而不复制临床内容。

威胁工作表列出典型滥用场景：撤销后刷新竞态、睡眠数据被用于无关目的、支持工具暴露记录、已删除连接静默重连、导出包含隐藏源字段。每个场景对应预防、检测和恢复措施。

回归测试规范包含三个负面用例和一个正面用例：撤销后过期任务、目的扩展、重连；正面用例是授权有效期内刷新和撤销完成后新建授予。验收标准检查控制平面、数据平面和证据平面：控制平面必须拒绝过期或越权权限，数据平面拒绝后不得持久化新获取数据，证据平面记录触发的规则且不含健康内容。

该模型不验证具体实现或监管状态，仅使授权声明可证伪。关键提问：同意变更后，哪些排队、缓存、导出和派生对象仍可移动，以及每个对象已停止的证据是什么？

#开发者 #工具 #安全 #威胁模型 #健康仪表盘 #同意边界 #OpenAI #ChatGPT #AppleHealth
@DevToolboxHub

本地健康导出字段校验 CLI

这个小工具的目标很简单：在本地检查 JSON 健康导出文件，如果包含接收者未请求的字段，就拒绝通过（fail closed）。它不解析医疗数据，不上传任何内容，是一个介于「导出完成」和「文件共享」之间的窄范围预检。触发背景是 OpenAI 于 2026 年 7 月 23 日宣布的 Health in ChatGPT 产品推送，面向美国 18 岁以上已登录用户（网页与 iOS），支持连接病历和 Apple Health，可查看化验、药物、活动、睡眠等信息。OpenAI 称连接数据与相关对话不会用于基础模型训练或广告定向。

该验证器使用白名单（allowlist）而非黑名单（denylist）来规避意外泄露——黑名单只检查已知敏感键，而白名单要求每披露字段都经过审批，能捕获源设备、原始记录 ID、时区等隐藏元数据。下面是一个示例实现（Python 3 脚本，作为 validate_export.py 保存）：

```python
#!/usr/bin/env python3
import argparse, json, sys
from pathlib import Path

ALLOWED = {"subject", "type", "day", "value"}
FORBIDDEN = {"name", "email", "address", "phone", "notes"}

def check(path: Path):
errors = []
for number, raw in enumerate(path.read_text().splitlines(), 1):
try:
row = json.loads(raw)
except json.JSONDecodeError as exc:
errors.append(f"line {number}: invalid JSON ({exc.msg})")
continue
keys = set(row) if isinstance(row, dict) else set()
extra = keys - ALLOWED
found = keys & FORBIDDEN
if not isinstance(row, dict):
errors.append(f"line {number}: object required")
if extra:
errors.append(f"line {number}: unexpected={sorted(extra)}")
if found:
errors.append(f"line {number}: forbidden={sorted(found)}")
return errors

p = argparse.ArgumentParser()
p.add_argument("file", type=Path)
args = p.parse_args()
problems = check(args.file)
print("REJECT" if problems else "ACCEPT")
for problem in problems:
print(problem, file=sys.stderr)
raise SystemExit(bool(problems))
```

使用方法：python3 validate_export.py export.ndjson。如果文件中出现 "notes":"call after lunch" 这样的字段，会同时报出 unexpected 和 forbidden 两种错误并退出。

分享前建议增加三个低成本检查：随机浏览十行并统计总行数；通过带外方式确认目的地和删除日期；从允许字段生成新文件，而非原地修改原文件。该工具仅校验顶级键名，无法检测允许字符串内隐藏的标识值、链接攻击、畸形日期、重复行或重识别风险。OpenAI 描述的健康体验为「支持」，不替代医疗诊断或治疗；本地 schema 校验的作用更小：只能减少意外泄露，不能判断数据的准确性、必要性或临床意义。

#开发者 #工具 #CLI #Python #隐私 #OpenAI #ChatGPT #Health #数据校验
@DevToolboxHub

用Python实现健康记录数据最小化过滤器

OpenAI 在 2026 年 7 月 23 日宣布 ChatGPT Health 功能，覆盖符合条件的美国用户（18 岁以上，登录后使用网页或 iOS），可连接病历和 Apple Health，仪表盘展示化验、用药、活动、睡眠等信息。OpenAI 称已连接数据和相关对话不用于训练基础模型或定向广告。

这篇教程用一个迷你 Python 程序演示“数据最小化”——如何让程序证明一个目的只接收原记录中的部分字段。例如，输入包含 date、steps、sleep_minutes、medication、note，但 activity_summary 目的只应得到 date 和 steps。

代码使用 Python 3.11+ 和标准库，定义 POLICY 字典映射目的到允许字段。minimize 函数对未知目的抛出 ValueError（fail-closed），而非返回全部字段。测试用例验证精确输出、输入不被修改、未知目的失败闭合。建议先测试异常输入（如拼写错误的目的名），确保断言能检测多余字段。

本练习只处理扁平字典，不处理值清洗、嵌套临床格式、匿名化、文件安全或集成任何已发布服务。示例数值纯属虚构，无医学意义。切勿未经完整的隐私与安全审查就用于生产健康数据控制。

#开发者 #工具 #Python #数据最小化 #隐私 #OpenAIHealth #ChatGPTHealth #单元测试
@DevToolboxHub

DeepDoc：离线解析文档为Markdown的单二进制工具

在构建RAG管道或搜索功能时，从docx、pdf等文件中提取文本总是一道绕不开的槛。现有方案要么依赖JVM（Apache Tika），要么需要Python环境及模型下载（unstructured、Docling），要么得上传云端（LlamaParse）。DeepDoc提供另一种选择：一个静态Rust二进制，无JVM、无Python、无模型下载、不连网，单文件即可运行。

> DeepDoc将每种格式解析为统一的文档模型（标题、段落、列表、表格、元数据、页码），再序列化为Markdown或JSON。v0.1支持13种原生数字格式：docx、pptx、xlsx、odt、ods、odp、epub、html、rtf、csv、md、txt及纯文本PDF。递归处理文件夹，输出保持目录结构。
>
> 对于RAG场景，DeepDoc按块边界切分，同时保留标题层级路径和字节范围作为元数据，确保检索时上下文不丢失。非OCR工具，扫描PDF会被检测并报错退出（返回码4），避免污染索引。也可作为Rust库使用，直接嵌入服务。
>
> 示例：deepdoc report.docx 直接输出带表格的Markdown；deepdoc ./docs --recursive -o out/ 批量处理并镜像目录。

DeepDoc是本地优先、轻依赖的工具链（DeepLab系列）之一，开源（MIT / Apache 2.0），v0.1已发布。

GitHub

#开发者 #工具 #DeepDoc #Rust #RAG #文档解析 #离线 #开源
@DevToolboxHub

APRF: AI生产就绪的硬门控框架

大多数团队把LLM功能当落地页来发布——合并PR、看演示、庆祝，然后现实打脸：提示注入泄露客户CRM、编码Agent提交密钥、支持机器人虚构退款导致诉讼、遗忘的API密钥一夜烧掉$82k。这些失败并非模型不够聪明，而是生产系统缺少生产门控。APRF是一个门控的、机器可读的生产就绪框架，提供代码、YAML门控和CI，本周就能接上。

APRF不是认证、不是合作伙伴网络、不是给董事会的0–100“就绪分数”。它是必过式方法论：强制检查要么通过，要么阻止发布。推荐控制从不平均进入门控。核心原则：门控结果 = ALL(强制检查通过) — 一项失败即阻断；能力 = 各支柱最小值 — 不允许平均分掩盖弱点。当前版本v0.10包含8个域（安全、安全、数据、模型生命周期、Agent、可靠性、成本、治理）、27个支柱、核心配置41个门控（Tier‑2）、受控配置61个门控（Tier‑3/合规系统），以及RAG、Agent、语音、编码Agent等附加透镜。机读规范与自证声明JSON均可获取。附完整实现示例：TypeScript工具白名单+模式验证、Python不可绕过的审批、YAML策略包（与app版本绑定）、GitHub Actions门控CI（检查证据文件存在性）、以及自证声明JSON模板。一个门控失败即阻止发布，没有“87%就绪”。

适合正在交付Agent、RAG、语音、编码助手的工程师，平台/MLOps团队厌倦了“我们很小心”的模糊说法，安全人员需要能映射到测试和配置的AI控制。APRF不会给你“对所有都合规”的徽章——这正是它的价值所在。贡献与讨论通过公开RFC进行。

#开发者 #工具 #APRF #StackRail #LLM #AI安全 #生产就绪
@DevToolboxHub

三款Chrome扩展提升开发工作流

一位开发者注意到日常工作中的三个小痛点——在随机网站上粘贴JSON格式化、复制JWT到jwt.io调试、切换到字符计数网站检查字数——于是花几个周末构建了三个Chrome扩展来解决它们。

PayloadPeek
JSON格式化工具，支持折叠语法高亮树、一键生成TypeScript接口、从JSON结构推断SQL schema（CREATE TABLE）、Ctrl+F搜索、点击复制任意值。最实用的功能是TypeScript Generator，处理陌生API时无需手写接口。

BearerPeek
JWT解码器，附带安全分析面板：标记缺失exp声明（永不过期）、缺失aud声明（任何服务可接受）、算法设为"none"、过期的token及精确过期时长。自动扫描当前页面中JWT格式的字符串，在DevTools查看请求时可预填token。

TextPeek
字符和字数计数器，支持平台感知的限制：Twitter 280、LinkedIn 3000、Meta描述160、YouTube标题100等。选中任意网页文本右键即可看到即时计数，无需打开任何窗口。

构建经验
Manifest V3对权限非常严格：因请求未使用的tabs、scripting权限被拒两次，因从CDN加载highlight.js被拒一次。MV3下所有JS必须本地打包，不能加载外部脚本。首次提交通常被拒，但拒绝邮件具体可操作，仔细阅读并修复即可。构建三个小东西比一个大东西好：每个扩展专注一件事，Chrome商店列表更清晰、权限理由更简单、用户信任更高。本地处理是真正的差异点——“数据不离开浏览器”是开发者关心的，尤其对JWT token和API响应。所有扩展均使用Claude Code作为pair programmer，在周末全职工作之余开发。

作者将这些扩展放在ShipNano品牌下，计划持续推出小型专注工具。

#开发者 #工具 #PayloadPeek #BearerPeek #TextPeek #Chrome扩展 #ShipNano #JSON #JWT #字符计数
@DevToolboxHub

Vault：浏览器端的投资组合风险追踪器

大多数散户用电子表格或免费App管理投资，只能看到总价值和每日变动，看不到年化波动率、夏普比率、市场贝塔、最大回撤、持仓相关性等核心风险指标。机构投资者用了几十年的东西，散户只能看饼图。

Vault 是一个开源的投资组合追踪器，基于 React 19 和 Vite 构建，通过 EODHD API 获取实时市场数据，在浏览器本地计算六项指标：收益（对比标普500）、分散度（HHI指数）、风险（年化波动率、夏普比率、95% VaR）、回撤（最大回撤曲线）、相关性（皮尔逊矩阵）和行业敞口（GICS细分）。不设后端，不存账户，持仓数据仅保存在 localStorage，不上传任何第三方服务器。

所有数学计算集中在单个文件 src/utils/finance.js，不依赖外部统计库，从零实现时间加权收益、波动率、夏普比率、贝塔、回撤、相关性矩阵和集中度指数。这些公式并不神秘，大多数付费工具只是把它们锁在付费墙后。

六项指标核心算法
时间加权收益：每日以前一日收盘价加权，避免月中新增持仓扭曲日收益。
波动率与夏普比率：日收益率标准差×√252，再对可配置无风险利率计算夏普比率。
贝塔：投资组合与标普500（GSPC.INDX）的协方差除以基准方差。
回撤：增长指数曲线（基数100）从滚动峰值的百分比跌幅。
相关性矩阵：按日期对齐的资产间皮尔逊相关系数。
集中度（HHI）：赫尔芬达-赫希曼指数应用于仓位权重。

添加持仓时，EODHD 的 Search + EOD 端点自动补全代码和买入日收盘价，随后渲染收益曲线、相关性热图和行业敞口，无需手动构建公式或重复输入价格。

代码地址：GitHub

#开发者 #工具 #Vault #EODHD #投资组合 #风险指标 #React #开源
@DevToolboxHub

说谎的数字：重建真正的Claude Code用量仪表盘

一位开发者在使用 Claude Code 月订阅时，因夜间自动化脚本消耗了两周额度，账户被锁定 4 天，不得不以原价购买额外 Token。这促使他构建一个用量仪表盘，过程历经四次失败迭代，每个版本都揭示一个关键教训。

第一次：自行估算每周 $4,690 限额，显示已用 13%——这个数字完全虚构，却看起来像真实测量。
第二次：从 claude.ai 抓取真实百分比 12%，但没有时间参考点——12% 在第一天意味着太快，最后一天意味着浪费。
第三次：改为计算剩余可用时间和重置时间，发现 Anthropic 的每周限额是固定时钟（每周一 13:00 重置），未用余额不结转，慢速使用等于浪费。
第四次：用贝叶斯统计处理早期波动大的问题，边界测试发现两个 bug——统计容忍度不应翻转判断结论；周期前 24 小时数据不足时不发出预警。此外，数据缺失时仪表盘应诚实显示“数据不可用”，而非用虚假数字保持沉默。

最终仪表盘在第二天就能用一句话告诉你：“按当前速度，额度不够撑到周五。”作者强调：没有来源的可信数字比明显缺口更危险，输入缺失时保持沉默的数字比错误数字更糟。

#开发者 #工具 #ClaudeCode #Anthropic #用量监控 #自动化
@DevToolboxHub

Apache Airflow与.NET 10集成指南

通过HTTP集成Apache Airflow 3与.NET 10，无需用C#重写DAG。服务端保持Airflow负责调度与执行，.NET仅通过REST API/v2触发DAG Run、认证JWT并轮询状态。指南覆盖端到端流程：生成可追踪的dag_run_id、正确序列化config、复用令牌、处理401后自动续期、设置超时与取消传播。

预备环境需.NET 10 SDK、Docker Compose 2.14+、至少4GB内存。仓库提供Airflow 3.3.0、PostgreSQL 16及示例DAG。使用LocalExecutor以简化测试。
认证：POST /auth/token获取JWT，之后通过Authorization: Bearer发送。客户端读取exp避免频繁刷新，并用SemaphoreSlim防止并发续期。
触发：POST /api/v2/dags/{dag_id}/dagRuns，必需字段dag_run_id、conf、logical_date（可null）。响应返回DAG Run对象，state初始为queued。
监控：GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}，轮询间隔5-10秒，直到state为success、failed或canceled。使用CancellationTokenSource设置总超时（如10分钟）。
关键实践：dag_run_id应包含业务键以确保幂等性；conf只传小引用（ID、URI），不传密文或大负载；失败时区分401（续期）、403（权限不足）等，仅GET允许指数退避重试。

完整代码示例（含Docker compose、客户端实现、Minimal API）见仓库BlogSamples/Orchestration/Airflow。

#开发者 #工具 #ApacheAirflow #dotnet10 #CSharp #DAG #JWT #DevOps #API
@DevToolboxHub

约80行脚本为营销文档做CI校验

作者的个人项目 lans.cloud 提供 100 多个免费浏览器工具。发文章、目录列表、推销邮件里提到的工具数量却不断出错——37、50、51、又变成50。代码有测试，文档会漂移，营销文案漂移最严重，因为没人执行校验。于是作者用大约80行脚本把营销文档放进CI：从代码注册表中提取真实工具数量，在git push前检查所有仍可编辑的文档里提到的数字是否一致，不一致则阻止提交。

关键设计：只检查当前活文档（后续会复制的），已发送邮件、归档旧文保留原数字。第一次运行就揪出一条过时的“41”，第二天又批量发现16处错误。作者感叹，营销文案是在别人头脑中执行的代码，应该像测试代码一样测试它。

#开发者 #工具 #CI #自动化 #营销文档 #事实检查 #lanscloud #sideproject
@DevToolboxHub

用 Claude Code CLI 当 Prism provider

一位 Laravel 开发者把已有 Claude Code 订阅利用起来，将 Claude Code CLI 封装成 Prism provider，从而在不额外支付 API 费用的情况下继续使用 Prism 的 LLM 调用接口。整套实现只有约 200 行代码，通过 stdin/stdout 与 CLI 交互，并保留了按环境变量切换 provider 的能力。

核心思路：Prism 的 provider 是扩展自 Prism\Prism\Providers\Provider 的类。这里只需实现 text() 和 structured() 两个方法，不支持 embedding、图片和流式。

CLI 调用输出包含 is_error、result、usage、model，可直接映射到 Prism 的 TextResponse / StructuredResponse。

安全要点：命令参数用数组传给 Laravel Process（避免 shell 注入）；用户 prompt 走 stdin 而非 argv；工作目录设为 sys_get_temp_dir() 避免项目指令泄漏；额外检查 envelope 中的 is_error 字段。

结构化输出模拟：CLI 不支持原生 JSON schema，因此在 prompt 末尾拼接 schema 要求，并在解析时先尝试直接 json_decode，再剥离 markdown 代码块，最后截取首尾大括号。

注册方式：在 ServiceProvider 的 boot 中通过 PrismManager::extend() 注册闭包，确保 Octane 下每次解析都重新读取配置。

切换 provider 只需修改环境变量，例如 PRISM_TEXT_PROVIDER=claude-cli PRISM_TEXT_MODEL=claude-haiku-4-5。resolveModel 方法会捕获旧模型名并回退到默认值。

注意：CLI 调用慢（大 prompt 30-90 秒），需注意超时链设置；容器内需安装 Node.js；高并发下进程创建开销大，不适合生产规模流量。对于 solo 开发或小产品，可大幅节省 API 成本。

#开发者 #工具 #Prism #ClaudeCode #CLI #Laravel #LLM
@DevToolboxHub

组织 CLAUDE.md、Skills 与 Agents 的最佳实践

为 Claude Code 等编码代理配置指令文件时，常见误区是同一套知识被复制到 CLAUDE.md、skills、agent 定义和参考文档四类文件中，导致各份独立漂移。经审计发现，这种“自信的错误”成本极高——样式文档推荐了与构建配置不匹配的 CSS-Modules 模式，测试模板在 beforeAll 中设置 mock 却被 test setup 文件在每个测试后重置，渲染组件缺少必要 Provider。每个错误文档都会让代理多花数千 token 的调试循环。

正确做法是按“何时加载、谁需要”决定内容归属：
- 每次会话都加载的规则放 CLAUDE.md / AGENTS.md，保持简短（3 行内 + 链接到 skill）
- 只有特定任务需要的深度知识放 skill（如样式机制、数据获取模式、测试配方），描述加载后才触发
- 角色或流程而非知识放 agent（定义工作流完成标准，调用哪些 skill），保持薄层
- 绝不可跳过的检查用 hook（格式化、lint）——代码规则比文字要求可靠

核心原则：每个事实只存在于一个文件，其他文件均引用它。模式超过几行就放入 skill，CLAUDE.md 仅放链接。

验证文档像验证代码一样：先用 grep 检查文档示例是否真实存在于代码库（如“prefetchQuery”零使用，“recommendedHelper”仅 1/50 测试文件使用）；再用子代理仅凭文档回答实现问题，对比实际代码评分。若代理按文档生成的代码会失败，则文档未通过，修复后再合并。

这一重组成果显著：典型功能任务上下文缩小约 11%，约定变更现在只需改 1 个文件而非 3 个，且文档不再生成损坏的样式和失败测试——每次代理踩坑省去数千 token 调试。

#开发者 #工具 #Claude #ClaudeCode #Agent #工程效率 #文档管理 #CodingAgent
@DevToolboxHub

Empire LLM for Codex：外部模型只贡献证据，不掌权

面对多个AI模型涌入代码审查场景，混乱与成本同步飙升：模型擅自编辑文件、执行命令、甚至自行审批补丁。Empire LLM for Codex 为 Codex 设计的插件，用一条原则解决这一痛点——外部模型贡献证据，而非权威。

Codex 保持领导地位。插件通过 OpenRouter 路由有限请求，应用能力/隐私/可用性/成本策略，返回带来源和成本的响应。外部模型无法编辑项目、执行代码、批准自己的提案或静默合并结果。Codex 评估后决定是否采纳。

具体实现中，请求被严格界定，响应附带着 provider、model、tokens、cost 和引用证据。开发者只需安装插件、定义最小上下文任务、并在行动前阅读“收据”——使用它如同对待外部顾问的建议：有用但绝不自动生效。同样，模型生成的图表、原型等媒体也按此流程处理：生产、标记、返回，由 Codex 决定是否放入资源文件夹。

这种架构强制了职责分离：更多模型并不自动产出更多智能，反而带来更多成本与模糊性。插件设立了三个关键边界：有限请求范围、每份响应的溯源、以及明确拒绝授予仓库权限。目前尚缺审查质量、假阳性率和成本方差等公开基准，但“Codex 主导、外部模型提供证据”的决策本身不依赖单一数字。

如果你已经在 Codex 中拉入多个模型，这是在不授予它们“钥匙”的前提下，最干净的做法。

#开发者 #工具 #EmpireLLM #Codex #AICodeReview #OpenRouter
@DevToolboxHub

SonicJS 认证问题排查指南

SonicJS 部署到 Cloudflare Workers 后，可能会遇到用户无法登录、权限不足或随意注册等问题。以下是在生产环境中必须处理的认证配置。

关闭公开注册：在 app config 中设置 disableSignUp: true，管理员通过 /admin/users/new 创建用户，确保同时写入 auth_user 和 auth_account。
密码存储不一致：Better Auth 读取 auth_account，部分流程只更新 auth_user.password_hash。使用 npm run set-password:prod 脚本同步两个存储，并通过环境变量 ADMIN_EMAIL 和 ADMIN_PASSWORD 种子初始管理员。
RBAC 权限问题：登录后有权限提示，通常是因为 auth_user.role 字段未映射到 RBAC 角色。使用 npm run promote-user:prod 提升用户权限，默认 editor 带 portal:access，admin 则全权限。
症状排查表：任何人可注册→关闭 signup；凭证未找到→运行 set-password；登录后无权限→运行 promote-user；种子失败→检查 wrangler.toml 和 D1 绑定；部署后认证异常→重新设置 BETTER_AUTH_SECRET 和 JWT_SECRET。
使用 patch-package 修复框架 bug，但应优先升级上游版本。

最后，确保私有 CMS 的强化清单：禁用公开注册、种子 admin、创建用户写入双表、RBAC 含 portal:access、密码重设脚本同步双存储、生产密钥通过 wrangler secret put 设置、公开集合显式指定 access.public。

#开发者 #工具 #SonicJS #Cloudflare #BetterAuth #RBAC #Workers #CICD
@DevToolboxHub

2026年S3替代方案速览：自托管与兼容云

2026年Amazon S3替代方案分为两大阵营：免出站费的S3兼容云（Wasabi、Backblaze B2）和完全去锁定的自托管引擎（MinIO、RustFS、Ceph、SeaweedFS）。选择取决于你希望由谁托管——云服务商还是自己的机架。

关键对比
• MinIO（AGPLv3）：单个静态二进制，纠删码，对象锁定，单租户高IOPS场景标杆，商用嵌入需另购许可。
• RustFS（Apache 2.0）：Rust编写，许可宽松，目标高吞吐自托管，但社区规模和第三方工具仍弱于MinIO。
• Wasabi：专有许可，无出站费，热存储约$6.99/TB/月，API兼容但缺乏Athena/Lambda等生态。
• Backblaze B2：专有许可，出站免至存储量3倍，约$0.005/GB/月，适合备份和归档。
• Ceph（LGPLv2.1）：统一对象+块+文件，运营复杂度高，适合大规模存储。
• SeaweedFS：轻量级，大文件数和小对象优化，适用于内容农场。

迁移清单（以12TB为例）
部署目标（MinIO/RustFS/B2），用rclone sync --checksum拷贝，切换应用端点并保留S3作为回退一个计费周期，最后用rclone check验证。在1Gbps链路上迁移12TB约需一个周末，瓶颈通常是源端出站上限。

选择四问：谁运行（云/自托管）、出站模型（读多需免出站）、许可证（AGPLv3/Apache 2.0影响分发）、工作负载（单租户/混合/统一）。答案映射：云+免出站→Wasabi/B2；自托管+宽松许可+高吞吐→RustFS；自托管+成熟生态→MinIO；统一存储→Ceph。

选择建议：按上述四问定位，200GB的PoC比电子表格更有效。最流行的S3替代是MinIO（自托管标杆）和RustFS（Apache 2.0高吞吐），云上免出站则推荐Wasabi和Backblaze B2。

#开发者 #工具 #S3 #对象存储 #MinIO #RustFS #Ceph #Wasabi #BackblazeB2
@DevToolboxHub

mAPI-ng：让 Go API 自我诊断问题

厌倦了盯着 Grafana 面板来回比对？mAPI-ng 是一个为 Go 服务设计的诊断工具，不只看图表，而是关联 RED 指标（速率、错误、时长）与 Go 运行时信号、实例健康及下游 IO，直接给出可能根因和置信度，例如“内存/GC压力（高置信度）”“下游IO瓶颈（中等置信度）”“goroutine泄漏”，并附带“排除此原因”说明，避免黑盒幻觉。

接入极简：两个 import、一个中间件、一个环境变量，无需 YAML 配置或管理 Prometheus；数据存储使用 ClickHouse。整个方案 MIT 许可，可通过 make up 自托管，也提供托管版（含永久免费层），无锁定风险。

GitHub

#开发者 #工具 #Go #API #诊断 #开源 #监控 #ClickHouse #自托管
@DevToolboxHub