agent-harness-defense v0.2.0：双格IFC拦截代理权限提升

agent-harness-defense 是一个面向 LLM 编码代理的准入层，通过 plan-first 信息流策略阻止指令权限提升。它并非运行时防火墙，而是一个库：在变更应用前调用 run_admission() 传入代理提议操作的显式描述，返回放行或拒绝的裁决及理由。

决策核心是双格信息流控制引擎，每个数据带两个标签：机密性（是否秘密）与完整性（是否可信）。当动作依赖低完整性数据（如仓库 README），即使内容不含任何触发词，动作也会继承不信任——这正是它能捕获 v0.1 启发式方法（触发短语）漏掉的提示注入的原因。v0.1 启发式保留为备份信号。

引擎机制：evaluate_plan 对 depends_on 图做分量格连接，机密性取最大值，完整性取最小值——UNTRUSTED 值与 SYSTEM 意图连接后仍为 UNTRUSTED，阻断升级规则。读取按路径分类：仓库文本产生 UNTRUSTED 完整性，系统文件产生 SYSTEM。依赖不可信读取的写入被拒绝（no-upgrade），env.SECRET 写入公共接收器被拒绝（no-downgrade）。

审计发现并修复了一个真实缺陷：_step_initial_label 对每次读取都返回 (PUBLIC, SYSTEM)，导致传播仅靠 value_source 中的魔法前缀工作。修复后由 _classify_read_path 从路径派生读取标签，并添加回归测试。

验证结果：pytest 23 项通过（0.29s），ruff 与 bandit 检查干净。评估套件覆盖 3 个场景（README 注入、CLAUDE.md 范围扩展、自有秘密泄露场景），每个场景都有测试证明 v0.1 会放行而新引擎会拦截。

需明确其边界：不自动提取计划，Plan 必须由调用方显式提供；传播基于声明而非真实内容；评估语料仅 3 个场景且均为英文直白攻击文本；无真实跨迭代持久化，也从未在真实代理或生产流量上运行。作者定位为经严格审计的研究原型，而非开箱即用的生产防御。

仓库：GitHub

#开发者 #工具 #agentharnessdefense #LLM #安全 #IFC #提示注入 #AGPL #Python
@DevToolboxHub

GKE VPA 决策日志公开预览，提升自动伸缩可观测性

Vertical Pod Autoscaler（VPA）在生产环境常被视作黑箱，传统的 Kubernetes 事件只能短暂保存，导致夜间批任务被驱逐或就地扩容失败时难以追溯根因。GKE 公测的 VPA 决策日志将每一次资源推荐、驱逐、就地或重建调整以结构化 JSON 形式写入 Cloud Logging，形成永久审计轨迹。平台工程师可以通过 Logs Explorer 查询推荐置信度、操作状态等细节，快速定位低置信度推荐、就地扩容失败或驱逐原因，从而实现对垂直伸缩的全链路可视化。

VPA 决策日志的四类操作
• UPDATE_RECOMMENDATION：每分钟输出一次原始推荐及上下限、置信度。
• EVICT_POD：在 Recreate 模式或就地扩容失败时记录驱逐事件。
• APPLY_RECOMMENDATION_ON_EVICTION：新调度 Pod 接收调整后记录。
• APPLY_RECOMMENDATION_IN_PLACE：就地修改容器资源时记录。

每条日志包含 state（SUCCEEDED、SKIPPED、FAILED）和 reason，帮助判断是否受限于 Autopilot 配额或自定义策略。confidence 字段区分 LOW（样本 <10）和 HIGH（样本 ≥10），指导是否需要延长采样期。

开启方式
新建集群：在 --logging 参数加入 KCP_VPA（如 --logging=SYSTEM,KCP_VPA）。
已有集群：使用 gcloud container clusters update 同样添加 KCP_VPA，并通过 gcloud container clusters describe 验证组件已启用。

实用查询示例（在 Logs Explorer）
- 查看特定工作负载的所有 VPA 决策：resource.type="k8s_control_plane_component" … jsonPayload.target.name="WORKLOAD_NAME"
- 查找就地扩容被跳过或失败的记录：jsonPayload.operation="APPLY_RECOMMENDATION_IN_PLACE" jsonPayload.state=("SKIPPED" OR "FAILED")
- 过滤低置信度推荐：jsonPayload.operation="UPDATE_RECOMMENDATION" jsonPayload.confidence="LOW"

通过持久化的 VPA 决策日志，平台团队不仅能快速排查伸缩异常，还能为 AI 自动治理或意图驱动的资源优化提供可靠数据支撑，真正实现容器资源的透明、可审计的自动右-sizing。

#开发者 #工具 #GKE #VPA #VerticalPodAutoscaler #GoogleCloud
@DevToolboxHub

DuckDB：直接在 CSV 上跑 SQL，无需导入

DuckDB 让你把 CSV 当作表直接查询。只需一行安装命令 python -m pip install duckdb，随后在 SQL 的 FROM 子句中写文件名（或使用 * 匹配文件夹），即可得到完整结果。它会自动推断列类型，支持日期、整数、文本、浮点等，返回的结果表会在列名下显示类型，方便检查。

- 一次性查询：SELECT Country, COUNT(*) AS invoices, ROUND(SUM(Total),2) AS revenue FROM 'invoices.csv' GROUP BY Country ORDER BY revenue DESC LIMIT 5
- 批量文件：SELECT COUNT(*) FROM 'months/*.csv' 直接把同结构文件合并查询。
- 与 pandas 互通：.df() 返回 DataFrame，或直接 SELECT * FROM my_dataframe。

DuckDB 适合一次性分析大文件或文件夹，SQLite 仍是持久数据库的首选。

github.com/michaelnocito/duckdb-demo

#开发者 #工具 #DuckDB #CSV #Python #pandas #SQL #数据分析
@DevToolboxHub

PostgreSQL INCLUDE 索引的真实用途

PostgreSQL 11 引入的 INCLUDE 子句常被说成是为了支持索引覆盖扫描（index‑only scan），但覆盖索引在 9.2 之前的版本已经可以通过把所有查询列放入键列实现。INCLUDE 的核心价值在于：它允许在索引中额外存放列而不让这些列参与 B‑tree 的键排序和导航，从而在唯一约束、更新成本以及上层树结构上带来优势。

使用 INCLUDE 可以在保持索引大小不变的情况下，将不需要参与排序的列作为纯粹的负载存储，避免它们出现在分支页的键元组里，减小内部页面占用。对唯一约束而言，只有键列才会影响唯一性检查，INCLUDE 列不会破坏已有的唯一索引定义。

此外，INCLUDE 列不需要对应的操作符类，因而可以包含没有定义比较运算符的类型；在仅更新这些列时，PostgreSQL 还能利用自底向上的索引删除优化，提升写入性能。唯一限制是表达式不能作为 INCLUDE 列，若需要覆盖 ORDER BY，则必须把相应列放入键列。

关键区别

- 键列：参与 B‑tree 导航，出现在所有层级的分支页。
- INCLUDE 列：仅作为叶子页的额外负载，不参与键比较。

性能影响
- 对于只读查询，二者都能实现索引覆盖扫描。
- INCLUDE 索引在上层树更小，可能降低缓存压力。
- 但包含非键列会关闭 B‑tree 去重，导致在某些情况下索引体积略增。

在实际使用时，若仅需避免表访问而不改变唯一约束或排序需求，INCLUDE 是更轻量的选择；若查询需要排序或唯一约束涉及该列，则仍需将其放入键列。

#开发者 #工具 #PostgreSQL #INCLUDE #Btree #索引 @开发者工具库频道号
@DevToolboxHub

Claude Code 配置的隐藏代价：9 857 Token

在 Claude Code 中安装的 107 个 skill、38 个 agent 和 15 个 command，会在每次会话启动时占用约 9 857 Token 的上下文空间，这部分费用在你输入任何字符之前就已经产生。

每个 skill 有两类成本：
- 执行成本：skill 被触发时加载的代码量，可见且相对公平。
- 描述租金：所有已安装的 skill、agent、command 的描述文本会始终占用上下文窗口，即使从未触发，这部分是永久租金，会在每次会话中扣除。

实际测算显示，这 9 857 Token 占用了约 5% 的 200 k 上下文窗口，虽然比例不算灾难，但因为大多数组件的触发率只有约 2%，导致大量“租金”被浪费。

通过运行作者提供的 cc-tax 脚本，你可以扫描本地 .claude 目录，统计每个组件描述的 Token 消耗，并据此删减一个月未使用的 skill，通常只需十分钟即可显著降低租金。

如果想自行测算并优化自己的 Claude Code 配置，可直接使用该脚本。

GitHub: GitHub

#开发者 #工具 #Claude #AI #PromptEngineering #TokenRent #ContextOptimization @开发者工具库
@DevToolboxHub

NVIDIA MPS 降低 ASR 推理成本

在大规模语音识别部署中，单模型占用整块 GPU 往往浪费算力。通过 NVIDIA CUDA MPS 在同一 GPU 上并发运行多个 CUDA 客户端，可在不改写代码的前提下提升利用率。本文在 Amazon EC2 g6e.4xlarge 与 g7e.4xlarge（均配备 48 GB L40S）上实验，找到的最佳并发点是平均延迟 ≤ 650 ms、p99 延迟 ≤ 1 000 ms，此时推理成本比单实例下降约 75%。

实现步骤包括：使用 NVIDIA Triton Inference Server 基础镜像 nvcr.io/nvidia/tritonserver:26.03-py3，在 Dockerfile.single 中通过 --build-arg LOCAL_NEMO_FILENAME=your_model.nemo 将模型打包进镜像，生成 parakeet-mps:latest。三层容器化结构保证了职责分离、配置切换和可重复基准测试。

关键经验：并发提升必须以延迟为约束，超过阈值即失去生产价值；实验结束后务必清理 EBS 卷，防止残留费用。对已有模型、GPU 使用率低的 ASR 场景，MPS 与 Triton 的组合提供了低成本的性能提升路径。

nvcr.io/nvidia/tritonserver:26.03-py3

#开发者 #工具 #NVIDIA #AWS #ASR #GPU共享 #Triton
@DevToolboxHub

高吞吐云存储解决8K视频掉帧

在高产出的视频后期制作中，渲染算力已不再是瓶颈，资产同步与云端上传才是主要卡点。普通消费云盘对单文件大小有限制（10‑15 GB）或在长时间上传时出现 socket 超时，导致 40‑90 GB 的 ProRes 或 RAW 主文件频繁中断。SpaceByte Cloud 采用无上限单文件流式传输，编辑器可直接将完整的多摄像机 8K 原始素材或高码率 ProRes 导出上传，无需手动拆分。

此外，通用云服务常在后台对上传视频进行转码压缩，导致 10‑bit 4:2:2 画面被降至 8‑bit 4:0 0，Log 曲线的暗部和亮部细节被削弱。SpaceByte 实行零转码策略，所有文件以 100% 位对位保存，确保远程调色、VFX 与音频团队使用的始终是原始未压缩数据。

网络层面，跨境路由的往返时延高达 140‑220 ms，严重限制 TCP 窗口扩展，使得即使千兆光纤也只能实现 15‑20 MB/s 的上传速度。SpaceByte 通过国内 IX 直连，实现 <15 ms 的本地对等，能够让工作站持续以 110 MB/s 以上的速率饱和千兆链路，显著缩短大文件上传时间。

这些特性让高比特率视频的审阅、交付与协作更加顺畅：无需压缩即可直接流式预览，支持细粒度的访问控制和下载配额管理，外部客户无需注册第三方账号即可获取高质量素材。

#开发者 #工具 #SpaceByte #视频编辑 #8K #印度 #云存储
@DevToolboxHub

一键 Docker 反向代理：nginx‑proxy + acme‑companion

在同一服务器上运行多个服务时，传统做法是每个服务都自行配置 Web 服务器和 SSL，维护成本高且易出错。使用 jwilder/nginx-proxy 可以让 Nginx 自动读取 Docker socket，根据容器的标签和环境变量生成路由配置，新增或下线服务时无需手动编辑 nginx.conf。再配合 nginxproxy/acme-companion，让 Let’s Encrypt 证书自动申请与续期，实现全站 HTTPS。

部署步骤概览：
1. 创建外部网络 webproxy，所有需要被代理的容器加入该网络。
2. 使用 Docker Compose 启动 nginx-proxy（暴露 80/443）和 acme-companion（共享证书卷），并挂载 Docker socket 与自定义 vhost 目录。
3. 为每个业务容器添加 VIRTUAL_HOST、VIRTUAL_PORT、LETSENCRYPT_HOST、LETSENCRYPT_EMAIL 环境变量，即可自动获得域名路由和 SSL。
4. 如需特殊规则（IP 白名单、额外 Header），在 /srv/nginx-vhosts/<domain> 放置自定义片段，nginx‑proxy 会自动加载。

这样，所有服务只需加入同一网络并声明域名，即可获得统一入口、自动 HTTPS 与可扩展的自定义 Nginx 配置，省去手动维护的繁琐。

nginxproxy/nginx-proxy
nginxproxy/acme-companion

#开发者 #工具 #nginxproxy #Docker #HTTPS #LetsEncrypt
@DevToolboxHub

完整示例：用仓库模式与依赖注入实现 SOLID

Repository Pattern 把所有与数据源（数据库、API、文件等）的交互封装进单一类，业务层只面对简洁的接口，就像图书馆的管理员负责取书，访客只需提出请求。代码中通过 IBookRepository 定义获取、查询、预订等操作，由 BookRepository 实现具体的数据访问。

Dependency Inversion Principle（DIP）要求高层模块依赖抽象而非具体实现，本文把业务类 BookReservationService 的构造函数参数声明为 IBookRepository 与 INotificationSender 接口。依赖注入（DI）则是把具体实现（BookRepository、EmailNotificationSender、SmsNotificationSender）在容器注册后自动注入，完成 DIP 的落地。

在示例里，单一职责体现在每个类只承担数据访问、业务规则或通知发送一种职责；开放/封闭体现在新增 SmsNotificationSender 时无需修改业务代码；里氏替换保证任意实现 INotificationSender 都可直接使用；接口隔离让 INotificationSender 只保留 SendAsync 一个方法，避免臃肿。

通过这套完整的图书预订系统，开发者可以直观看到 SOLID 五大原则在实际代码中的具体体现，并快速在自己的项目中复用相同的结构。

GitHub: GitHub

#开发者 #工具 #SOLID #RepositoryPattern #DependencyInjection #CSharp #DotNet
@DevToolboxHub

本地语义Shell实验：从 Needle2 到 llama.cpp + Granite

在一次语义Shell实验中，我尝试让本地模型把自然语言指令映射到具体工具，例如“copy report.pdf to backup” → filesystem.copy。模型只需理解意图，不生成Shell命令。

最初使用 Needle2，因其体积小、专注工具调用且支持本地运行，表现还算可用。但随着工具数量从5个扩展到50个，检索阶段出现两层决策：先筛选候选工具，再在其中选出最佳。若正确工具未进入候选集，后续就无从选择。为降低风险，我尝试将工具分组（每组5个）并并行评估，但不同组的置信分数是否可比仍不明确。

此外，工具描述的细节对小模型影响极大。仅用“Moves files from one place to another.”无法区分 filesystem.copy、filesystem.navigate、filesystem.rename，需要在描述中明确说明源文件会被删除等细节。

在尝试 C++ 原生运行时遇到平台兼容问题（ARM NEON 代码在 Intel Mac 上无法直接编译），我转而使用 llama.cpp 并加载 Granite‑4‑350M。结果出乎意料：模型在常规指令上能准确选出工具，在模糊或无匹配的输入上则直接返回“未找到合适工具”，避免了错误调用。Shell 可据此提示用户重新表述或手动选择。

实验表明，模型本身的完美并非关键，关键在于系统如何处理不确定性：意图解析 → 参数校验 → 缺失参数提示 → 策略确认 → 执行。只要外层逻辑能容错，模型不必完美。

结论：
- Needle2 仍适用于特定平台（如 ARM 目标），但在工具规模扩大、跨平台集成时存在隐性成本。
- llama.cpp + Granite 在本地语义工具调用上更稳健，尤其在处理无匹配或模糊输入时表现更好。
- 关注模型的失败模式、可移植性和置信度校准，比单纯追求演示效果更重要。

#开发者 #工具 #Needle2 #llama_cpp #Granite4_350M @开发者工具库频道
@DevToolboxHub