ZBLOG

ArkClaw架构分析：字节如何将OpenClaw从开源框架做成企业级SaaS

Mon, 06 Apr 2026 14:58:09 +0800

阿卡爪架构剖析，字节怎样把开源克洛从框架弄成企业级软件即服务。

引言

在武汉，火山引擎开启了ArkClaw万人体验季，这意味着AI Agent正式迈入SaaS化商业阶段。从技术架构层面来看，ArkClaw处理好了OpenClaw落地的两个关键问题，一个是部署门槛，另一个是企业数据集成。

一、SaaS化架构

┌─────────────┐

│ Web前端│ 浏览器直接访问

└──────┬──────┘

↓

┌──────────────┐

一种是，被称作Agent编排层的部分，另一种是，名为OpenClaw内核且处于云端的部分。

└──────┬───────┘

↓

┌──────────────┐

│ 模型调度层 │ 火山方舟（多模型自动选择）

└──────┬───────┘

↓

┌──────────────┐

│ 工具层│ 飞书SDK + 浏览器操控 + 文件系统

└──────┬───────┘

↓

┌──────────────┐

│ 数据层│ 企业知识管理平台

└──────────────┘

关键的设计方面所做出的决策是，进行多模型的调度，ArkClaw并非附着于单一的LLM，而是依据任务的类型，也就是代码、文档或者分析，凭借自动的方式将其路由到最为适宜的模型那里，在工程这个范畴之内，这种方式相比较于OpenClaw的“用户自我选择模型”而言，对于并非技术领域的用户来讲，是更具适合性的。

二、企业化关键能力

企业知识管理平台

同场发布的知识管理平台是ArkClaw企业化的核心组件：

能力说明

文档索引自动索引企业内部文档

知识图谱构建实体关系网络

多格式接入 PDF/Excel/数据库/API

权限管理基于角色的访问控制

Agent加上知识库，等于可基于企业数据来做决策的“数字合伙人”，这是从通用助手迈向企业级工具的关键跨越。

飞书深度集成

对飞书用户来讲，ArkClaw并非单纯的API调用那般简单的飞书适配，而是有着日程管理、多维表格CRUD、文档生成编辑、消息推送这些深度集成，ArkClaw在飞书里就是“AI执行层”。

三、OpenClaw与ArkClaw之间的技术权衡，OpenClaw和ArkClaw是不同的对象，存在着技术方面的权衡情况。

有个概念叫维度，其中一部分是OpenClaw，这是自行构建的那种，还有一部分是ArkClaw，属于SaaS模式的那种。

定制性极高中等

部署成本高零

数据主权完全依赖平台

模型灵活度任意平台内置

企业集成需自建开箱即用（飞书）

安全审计自建平台提供

在团队具备技术能力并且对数据敏感的情境下，OpenClaw进行自行构建依旧是更为优良的抉择。在中小企业以及非技术团队的状况里，ArkClaw的SaaS模式明显地有降低采用门槛之举。

四、对工程实践的启示

一种关于Agent SaaS化的设计模式呈现为：多模型进行调度，知识库实现集成，工具达成标准化，而这些ArkClaw的设计能够供那些自建Agent产品的企业去参考使用以辅助构建企业知识库，企业知识库乃是Agent企业化的基石所在，因为没有企业数据的Agent仅仅算得上是通用助手，只有获取了企业数据才堪称是“合伙人”，另外还存在一个SaaS与自建的选择框架，即数据敏感度高的情况下倾向选择自建的方式，效率优先的情形下则倾向选择SaaS的方式，并且此类判断标准将会适用于越来越多的Agent产品。

解锁 AI 与数据库的智能对话：从 MCP 协议到 Cloudberry MCP Server 的深度应用

Mon, 06 Apr 2026 14:54:27 +0800

Apache Cloudberry™ (处于孵化期) 这一项目源于 Greenplum 与 PostgreSQL，是 Apache 软件基金会正在进行孵化的项目，它具备大规模分析能力，适用于 AI/ML 工作负载，作为领先的致力于建设企业级数据仓库的开源 MPP 数据库，有着相应的用途。

https://github.com/apache/cloudberry 这个网址对应的是 GitHub。

文章作者：杨胜文，酷克数据首席科学家；整理：酷克数据

身处于人工智能时代当中，大型语言模型也就是 LLM，像 Claude 或者 GPT 这样的，已然摇身一变成为了开发者的数据分析师的得力助手。但然而呢，一旦当这个 LLM 需要去访问外部数据源如同数据库这般的时候，传统方法常常会面临安全方面的隐患，接口不统一的状况以及效率低下的挑战。Model Context Protocol 也就是 MCP 协议的现身出现，恰似是一扇标准化的大门，开启了 LLM 与外部系统进行无缝协作的一个全新纪元。

首当其冲的是，本文会对 MCP 协议的核心价值予以剖析，紧接着，会将关注点投向 Apache Cloudberry MCP Server，它可是专门针对高性能分析数据库 Apache Cloudberry 而打造的 MCP 实现。最终，借助把 LLM 与公开数据集相结合的实际应用案例，来呈现怎样把抽象协议转变为鲜活且具实操性的数据库交互体验。

MCP 协议：AI 应用的“上下文桥梁”

Model Context Protocol ，也就是 MCP ，是开源标准协议，它由 Anthropic 在 2024 年 11 月 25 日发布，目的是解决 LLM 跟外部数据源、工具之间的通信难题。简而言之，MCP 提供了一个通用的接口框架，使得像 Claude 或者 GPT 这样的 AI 应用，能够安全且高效地“读取文件、执行函数并处理上下文提示”。

好的呀，MCP也就是Model Context Protocol，它的确是当下用来解决LLM跟外部工具相互连接时所存在的“碎片化”状况的一种有效办法呢。

传统维度接口的痛点，(Traditional)MCP的优势，以及(MCP Solution)解决方案。

标准化

每个工具需自定义 Schema，不同模型间不通用

将 JSON 接口进行统一，有一份代码，能适配所有与 MCP 兼容的 LLM。

安全性

逻辑零散，易受 Prompt 注入攻击

参数化执行 + 细粒度权限校验，确保执行环境安全

可扩展性

集成逻辑复杂，新增工具往往需要重写大量代码

热插拔工具架构，支持动态发现与异步流式加载

效率

多为同步阻塞模式，高并发下延迟严重

基于 WebSocket/SSE，支持并发处理与毫秒级响应

MCP 的核心机制与优势

MCP的设计灵感源自HTTP以及WebSocket等已成熟的协议，却专门是为AI场景做的优化，它把外部系统包装成为“工具”（Tools）还有“资源”（Resources），借由JSON格式的请求 - 响应流达成双向通信，关键组件包含：

工具调用（Tool Calls）：

LLM能够动态地去调用预先定义好的函数，像是那么“执行SQL查询”或者是“获取文件元数据”这类的，并且它是不需要进行硬编码API的。

上下文注入（Context Injection）：

协议具备支持能力，可将外部数据实时注入到LLM的提示里面，以此来保证AI决策是基于最新信息做出的。

安全沙箱：

有着内置的验证机制，能够防止 SQL 注入情况出现，还可避免越权访问现象发生，并且支持读写权限方面的控制。

为何 MCP 这般重要呢？在 2025 年的时候，伴随 LLM 代理（Agents）的兴起，AI 不再是孤立存在的，而是作为需要跟数据库、API 等“世界”进行互动的实体而出现。MCP 把集成门槛给降低了，依据 Google Cloud 的报告，它能够把 AI 工具接入的时间缩短 70%。如今，MCP 已经被 OpenAI、LangChain 和 IBM 等巨头采用了，成为了 AI 生态的“TCP/IP”。

Cloudberry MCP 服务器，MCP 于高性能数据库里得以完美实现落地。

存在一个名为Apache Cloudberry的事物，它属于开源的PostgreSQL兼容数据库范畴，专门针对海量规模分析（PB级）予以优化，具备支持PAX行列混合存储的特性，适用于数据仓库以及实时BI场景这两个领域。而Cloudberry MCP Server是其官方MCP实现，以一个轻量级服务器的形式存在，它把Cloudberry的数据库能力展现为MCP兼容的工具集。经由asyncpg驱动所构建的异步架构呀，它切实保障了在高并发情形之下的，那种低延迟的交互状况呢。

核心特性一览

红梅莓素MCP服务器，遵照MCP准则，给出资源端点与工具函数，涵盖从元数据问询直至性能优化的整个链路。以下详细罗列关键特性，依类别划分，方便开发者迅速定位。所有工具都支持参数式输入、安全核验（像SQL注入防范）以及异步运行，默认开启只读模式以保障数据安全。

先执行 pip install -e. 来进行简便安装，接着配置.env 文件，之后运行 python -m src.mcp.server 就能够启动 HTTP 模式或者 Stdio 模式，它支持 Claude Desktop、Cursor IDE 等集成，像 DB_HOST=localhost 这样的环境变量会让部署变得如同丝滑般顺畅。

于2026年初的那个最新版本里，Cloudberry MCP Server被做出优化，从而能够支持MCP 2.0规范，并且增添了异步批量查询的功能，它是适用于边缘计算场景的。

结合 LLM 在真实数据集上的应用：从提示到洞察的生动之旅

其魅力在于，MCP和LLM之间会产生“化学反应”，这种化学反应是，AI无需编写代码，仅靠自然语言提示，服务器借助MCP桥接来执行。我们以经典公开数据集DVD Rental为例，它是DVD租赁数据库，有16张表和约7万条租赁记录。模拟数据分析师的日常，从探索到优化，整个过程由LLM如Claude驱动Cloudberry MCP Server。

场景一：元数据探索——“告诉我这个数据库藏着什么宝贝？”

LLM 提示：

借助Cloudberry MCP，将DVD Rental数据库的schema以及主要表结构分列出来，这一举动被执行。

MCP 流程：

LLM 调用 Resources：

GET postgres://schemas

服务器响应 JSON：

{
  "schemas": ["public"],
  "tables": {
    "public": ["film", "rental", "customer", "payment"]
  }
}
````
LLM 注入上下文，生成描述：
> public schema 下有 film（电影表，包含 title、rental_rate 等列）和 rental（租赁表，记录 rental_date、customer_id）。
**生动输出（LLM 总结）：**
想象你是一家视频店老板，刚导入 DVD Rental 数据。LLM 瞬间绘出蓝图：
> 你的库存有 1000 部电影，去年租赁高峰在夏季。customer 表有 599 名忠实粉丝，平均每人租借 16 次。
这比手动 `pg_dump` 快 10 倍，避免了“迷失在 schema 森林”的尴尬。进一步调用：

get_table_ddl(public, film)


可生成完整 DDL，如：

CREATE TABLE public.film (

film_id integer NOT NULL,

...

);


直接用于迁移。
---
## 场景二：安全查询执行——“2006 年最火的喜剧电影是哪几部？”
**LLM 提示：**
> 查询 2006 年租赁最多的 5 部喜剧电影，并显示类别和次数。
**MCP 流程：**
LLM 生成 SQL：

SELECT

f.title, cat.name, COUNT(r.rental_id)

FROM

film f

JOIN ...

WHERE

DATE_PART('year', r.rental_date) = $1 AND cat.name = 'Comedy'

LIMIT 5;


调用 Tool：

执行查询，查询语句为查询，参数为参数，只读属性设置为真，进行这样的操作。


服务器验证（无注入风险）、执行，返回结果。
**结果表格（LLM 渲染，便于直观）：**
| 电影标题               | 类别     | 租赁次数 |
| ------------------ | ------ | ---- |
| Bucket Brotherhood | Comedy | 25   |
| Chitty Bang        | Comedy | 22   |
| Control Velvet     | Comedy | 20   |
| Sweet Homeward     | Comedy | 18   |
| Bright Foxes       | Comedy | 17   |
**洞察：**
LLM 续道：
> 这些爆款多为家庭喜剧，建议库存加倍。查询耗时 50ms，无需担心高峰期崩溃。
相比裸 SQL，这避免了参数错误（如年份写成字符串），并自动注入上下文：
> 基于 rental 表 16000+ 记录分析。
借助 `explain_query`，LLM 可进一步显示计划：

依循影片类别进行哈希连接活动啦，其成本范围是从零点零零至五千六百七十八点九零哟。


确认效率。
---
## 场景三：性能优化与健康检查——“我的查询为什么这么慢？”
**LLM 提示：**
> 分析 rental 表的慢查询，并建议索引。顺便检查数据库健康。
**MCP 流程：**
调用：

get_slow_queries(5)


返回：

rental-customer JOIN 平均 500ms


`explain_query` 输出计划：

顺序扫描在租赁这上面有花费花费的数值是12345。


预置提示 `suggest_indexes` 生成：

在rental表上，创建一个名为idx_rental_date的索引，该索引基于rental_date列。


`database_health_check` 输出：
> rental 表膨胀 15%，推荐 VACUUM；最后分析时间：2 天前。
**生动模拟：**
LLM 如资深 DBA 般回应：
> 慢因缺少日期索引——加后，查询提速 70%。健康分 85/100，rental 表 1.2GB 是大户，考虑分区。
在 DVD Rental 中，这直接将 BI 报告从小时级缩短到秒级。
`get_table_bloat_info()` 进一步揭示：
> 膨胀率 12%，预计节省 200MB 空间。
---
## 场景四：权限审计与对象管理——“谁在窥探我的客户数据？”
**LLM 提示：**
> 检查 customer 表的访问权限，并列出相关触发器。
**MCP 流程：**

把 (public, customer) 作为参数，调用 list_table_privileges 这个操作。


输出：

staff: SELECT/UPDATE

public: SELECT

list_users()


用户列表：

postgres, analyst, staff


输出：

audit_trigger，在插入之后，或者在更新之后。


**输出总结：**
LLM 总结：
> staff 角色有写权限，潜在风险；触发器确保审计日志完整。建议 REVOKE UPDATE ON customer FROM staff。
这在合规场景中，如 GDPR 检查，省时省力。
---
## 集成实践：Claude + Cloudberry MCP
在 Claude Desktop 配置 `mcp.json`：

"mcpServers": {

"cloudberry-dvd": {
  "command": "uvx",
  "args": ["--with", "cbmcp", "python", "-m", "cbmcp.server", "--mode", "stdio"],
  "env": {
    "DB_NAME": "dvdrental",
    "DB_USER": "postgres"
  }
}


启动后，Claude 即可“聊天式”操作：提示一出，MCP 流转，数据即现。适用于 Cursor 或 VS Code，扩展到生产如电商日志分析。`list_large_tables(10)` 可快速扫描大表，结合 `get_vacuum_info()` 自动化维护。
---
## 结语：MCP 时代，数据库“活”起来
从 MCP 协议的标准化桥梁，到 Cloudberry MCP Server 的安全高效实现，再到 LLM 在 DVD Rental 等数据集上的生动应用，这一生态链条正重塑数据交互。
开发者不再是 SQL 苦力，而是 AI 导演——安全、快速、直观。2026 年，试想将此扩展到实时 IoT 数据：你的 LLM 能否“预言”下个租赁热潮？立即上手，开启属于你的 AI-数据库冒险！

跨云可观测这么建：一套架构，成本砍 87%

Mon, 06 Apr 2026 14:37:57 +0800

客户诉求1.1 多云日志统一分析

在多云场景之中，其常见的形态呈现为，海外边缘的安全以及访问能力是由Cloudflare来承担的（涵盖WAF/CDN/Access），详细的日志借助Logpush统一落在AWS S3那里做低成本的归档还有合规留存；与此同时，总部的核心业务以及可观测体系常常已经在阿里云一侧运行了（像是应用/网关/业务日志进入SLS，告警与值班/工单体系也依据阿里云一侧来建设）。其结果便是，针对同一条用户请求，以及同一次攻击，还有同一次发布变更所形成的“证据链”，分别分布于 AWS 与阿里云两边，在一个平台内部难以达成统一检索，也难以进行关联分析，更难以实现闭环处置。

针对平台工程团队来讲，这当前情形致使的关键矛盾并非是“日志存放于何处”，而绝对是“分析以及运营行为在哪个地方达成闭环”。

1.2 降本与简化运维

若将 S3 用作日志存储，欲使数据得以“运用”（涵盖查询分析、可视化、告警联动等方面），通常而言还需额外的查询组件、ETL 组件，以及指标与告警组件协同配合，如此一来链路会变长，配置以及排障需跨越多个系统，进而运维复杂度会显著上升。

假设要将数据径直接入CloudWatch，那么采用CloudWatch Logs来进行采集以及存储，运用Logs Insights去做查询分析，借助Dashboards/Alarms来打造仪表盘以及告警闭环，整体成本常常是颇高的。

SLS 解决方案

紧接着，会一步一步地进行拆解，去介绍这一整套 SLS 解决方案里的数据导入功能，数据加工功能，数据查询分析功能，仪表盘展示功能，以及告警功能。

2.1 从 S3 将数据导入 SLS

于不少人眼中，数据导入难道不就是那“读取，传输，写入”这简单的三板斧么？然而当你所面对的竟是：

你会发现，这绝非一个简单的“复制粘贴”操作。

随后，会先将实际导入进程里碰到的难点阐释明晰，接着，把相对应的落地实行办法予以说明：

挑战一，海量小文件要做到“实时发现”并非易事，其中存在全量遍历与实时性的考量，还有增量遍历与完整性的权衡。

S3的ListObjects仅支持依照字典序展开遍历，并不支持“按照时间进行过滤”。在bucket/目录的历史文件数量非常庞大的时候，完成全量扫描一次或许会耗费很长时间；然而仅仅开展增量扫描又有可能因为文件名呈现乱序状态而导致遗漏文件。

其后果表现为，有可能新文件没能即刻被发现，而是出现延迟升高的状况，又或是在极端情景下会有所遗失，进而产生完整性方面的风险。

挑战二：吞吐得能够跟得上峰值，然而绝不能依靠“人工调参”（流量突发进而加上长尾拖累），挑战三：格式呈现为“混合大礼包”（压缩格式能够被识别，可是数据格式没办法自动去猜），挑战四：正确性需要可以进行交付（不会丢失数据、能够被补偿、能够定位到“究竟是哪个文件遭遇了问题”）

针对这些难点我们的设计方案：

对比维度双模式遍历SQS 事件驱动

新文件发现实时性

分钟级

秒级

配置复杂度

简单，无需额外配置

需配置 S3 事件通知和 SQS

可靠性

高（全量兜底）

依赖 SQS 可靠性

成本

仅 S3 API 调用

额外 SQS 费用

适用场景

标准日志导入

高实时性、文件名不规则

设计要点之四：点位以及状态的管理，加上重试还有隔离，再加上文件级别的追踪，使得“补数”能够得以落地实现。

2.2 一站式数据分析

被导入的数据仅仅是起始的第一个步骤，而完整的、具备可观测特性的闭合环路，还需要针对数据展开治理工作，进行交互式查询行为，实现可视化的展示效果以及具备智能告警功能。SLS把这些相关能力整合于统一的平台之上，以下对各环节所拥有的核心原理予以介绍。

数据加工：全托管流式 ETL

SLS数据加工是基于托管的实时消费任务，借助SPL语法来对日志开展流式处理，它具备全托管免运维的特性，拥有弹性伸缩能力，数据能在秒级呈现，还支持按行调试以及代码提示。

SLS 于日志 Pipeline 之上，将 SPL 引擎用作内核，此内核具备列式计算优势，拥有 SIMD 加速优势，是以 C++ 语言实现的优势。基于 SPL 引擎构建分布式架构时，我们重新设计了弹性机制，该机制并非只是存在于通常意义里按实例（K8s Pod 或是服务 CU）粒度的伸缩情况，而是能够按照 DataBlock 粒度（MB 级别）实现快速弹性。

场景能力：

查询分析：高性能引擎，秒级响应

高性能查询引擎由 SLS 提供，其支持索引模式，索引模式具备秒级响应百亿级数据的特性，同时也支持扫描模式，扫描模式用于轻量级分析。查询直接对索引起作用，不需要预建数据集，也不存在刷新延迟的情况。面临超大规模数据分析场景时，SLS 会提供 SQL 独享版，此版本涵盖SQL 增强和 SQL 完全精确两种模式。

查询引擎与能力：

仪表盘：丰富可视化，开箱即用

日志服务所提供的数据可视化工具是SLS仪表盘，它会把查询分析结果借助图形化界面去展示，仪表盘一般含有多个统计图表，这些统计图会对关键性能指标、重要数据以及分析结果进行汇总且呈现。

可视化能力：

告警：一站式智能运维平台

SLS告警乃是具备一站式告警监控、降噪、事务管理以及通知分派功能的智能运维平台，它是由告警监控、告警管理、通知（行动）管理这些子系统所构成的。当接入日志或者时序数据之后，在数分钟以内就能够创建监控任务、通知渠道以及告警策略。

功能优势：

2.运维进行简化，采用一体化来替代多产品组合，2.3.1提到AWS多产品组合，那么为了达成同样的闭环，通常需要哪些组件呢。

组件数量多，这并不必然就不好，然而，当你所具有的诉求乃是做到“统一口径”，做到 “分钟级闭环”，做到“低成本可控”的时候，多组件进而就意味着：

2.3.2 SLS 一体化 vs AWS 多产品组合

将“导入、加工、索引、查询、仪表盘、告警/事务”于 SLS 之内铸造成一个能被复用的工程模板，拿此模板提供首版交付，经策略去迭代成本以及效果。

出海企业日志分析架构升级案例背景与解决方案

有一家规模很大的、走向全球进行出海经营的企业，它的业务范围涵盖了欧洲、亚太以及北美等好多不同的区域，借助主流的CDN以及安全服务达成了全球范围内的访问加速以及Web应用防护。为了能够满足海外的数据合规还有审计方面的要求这个企业把它的安全以及访问日志凭借平台原有的日志推送能力也就是Logpush持续不断地归档到公有云对象存储当中，以此来用于长期的留存以及后续的分析。

此刻于 AWS 之上，借由多组件组合达成海外日志的分析跟监控，碰到了如下这般的问题：

除此之外，ETL要依靠Glue/Lambda，还得自己去维护，QuickSight进行可视化，需要另外授权，并且存在着同步延迟的情况，CloudWatch Alarms的配置比较分散，缺少统一的降噪能力，多种产品组合在一起，导致运维的复杂度很高，成本也无法控制等一系列问题。

基于阿里云 SLS 构建统一的可观测分析平台，实现：

3.1 数据链路

数据借助Cloudflare Logpush推送送往AWS S3海外各个Region进行归档，SLS凭借事件驱动或者定时扫描导入同一地域的Logstore，经过SPL加工之后汇聚到国内中心Logstore，以此支撑统一的查询分析、仪表盘以及告警。

3.1.1 SPL 数据加工示例

示例原始日志（Cloudflare WAF 日志）

Cloudflare WAF的原始日志示例，当中含有ClientIP、SecurityAction、SecuritySources等敏感以及安全字段，涵盖block/allow/challenge这三种安全动作场景，这些日志能够直接用以测试SPL加工语句。

{
  "EdgeStartTimestamp": "2024-12-25T10:30:00Z",
  "RayID": "abc123def456",
  "ClientIP": "203.0.113.50",
  "OriginIP": "10.0.0.100",
  "ClientRequestURI": "/api/v1/users?id=123",
  "ClientRequestMethod": "POST",
  "ClientRequestReferer": null,
  "SecurityAction": "block",
  "SecurityRuleID": "rule_001",
  "SecuritySources": "[{\"source\":\"waf\",\"action\":\"block\"}]",
  "OriginResponseStatus": 200,
  "OriginResponseTime": 150,
  "ResponseHeaders": "{\"x-cache\":\"MISS\"}"
}

海外侧完成数据治理，其中包括时间标准化，是关于IP转Geo地理信息，还涉及IP脱敏变成匿名指纹，以及安全元数据解析与风险标签化。最终借助project - away移除ClientIP、OriginIP等敏感字段，仅保留黄金字段用于跨境传输。

-- 核心追踪与时间标准化
* 
| extend __time__ = cast(to_unixtime(date_parse(EdgeStartTimestamp, '%Y-%m-%dT%H:%i:%SZ')) as bigint)
| extend RequestId = RayID
| extend RequestPath = url_extract_path(ClientRequestURI)
-- IP -> Geo（在海外完成）
| extend
    GeoCountry = ip_to_country(ClientIP),
    GeoRegion  = ip_to_province(ClientIP),
    GeoCity    = ip_to_city(ClientIP)
-- IP 脱敏：保留匿名指纹（可选），不跨境携带原始 IP
| extend ClientFingerprint = to_base64(sha256(to_utf8(ClientIP)))
-- 安全元数据解析/标签化
| expand-values -keep SecuritySources
| parse-json -prefix='Security' SecuritySources
| extend IsHighRisk = if(ClientRequestMethod = 'POST' and (ClientRequestReferer is null or SecurityAction = 'block'), 1, 0)
-- 最终降噪与字段投影
| project-away ClientIP, OriginIP, ResponseHeaders, RayID

加工后示例数据

加工完成的数据，已然达成了Geo富化，同样完成了IP脱敏，又实现了风险标签化，并且敏感字段给移除掉了，能直接用以供下游进行查询分析以及告警：

{
    "RequestPath": "/api/v1/users",
    "__time__": "1735122600",
    "RequestId": "abc123def456",
    "ClientFingerprint": "O1zTaFfLyH1ZqEHS03UiLSNMzwMX+4ZW7OsIVsDGgEg=",
    "OriginResponseTime": "150",
    "GeoCity": "理查森",
    "ClientRequestURI": "/api/v1/users?id=123",
    "IsHighRisk": "1",
    "EdgeStartTimestamp": "2024-12-25T10:30:00Z",
    "SecurityAction": "block",
    "SecurityRuleID": "rule_001",
    "Securityaction": "block",
    "GeoCountry": "美国",
    "GeoRegion": "德克萨斯州",
    "OriginResponseStatus": "200",
    "Securitysource": "waf",
    "ClientRequestMethod": "POST"
}

3.1.2 查询分析示例

WAF规则命中情况进行统计，按照规则，归集命中的次数，计算高风险所占的比例，统计独立攻击者的数量。

* | SELECT 
  SecurityRuleID,
  count(*) AS TotalHits,
  count_if(IsHighRisk = 1) AS HighRiskHits,
  approx_distinct(ClientFingerprint) AS UniqueClients
FROM log
WHERE SecurityRuleID IS NOT NULL AND SecurityRuleID <> ''
GROUP BY SecurityRuleID 
ORDER BY TotalHits DESC

攻击源地域排位在前十位的情况，是按照国家和城市来进行聚合，从而得出拦截的次数以及独立攻击者的数量。

* | SELECT 
  GeoCountry,
  GeoCity,
  count(*) AS AttackCount,
  approx_distinct(ClientFingerprint) AS UniqueAttackers
FROM log
WHERE SecurityAction = 'block'
GROUP BY GeoCountry, GeoCity
ORDER BY AttackCount DESC
LIMIT 10

示例 3：源站 5xx 的错误趋势是，要这般操作，即依照分钟去聚合错误的次数，还有错误率以及总的请求量。

* | SELECT 
  time_series(__time__, '1m', '%Y-%m-%d %H:%i:%s', '0') AS TimeBucket,
  count_if(OriginResponseStatus >= 500) AS Origin5xxCount,
  count_if(OriginResponseStatus >= 500) * 100.0 / count(*) AS Origin5xxRate,
  count(*) AS TotalRequests
FROM log
GROUP BY TimeBucket
ORDER BY TimeBucket

示例 4：针对请求延迟进行分位分析，此分析是按照路径来聚合 P50、P90 以及 P99 的延迟情况，进而实现对慢接口的定位。

* | SELECT 
  RequestPath,
  count(*) AS RequestCount,
  approx_percentile(OriginResponseTime, 0.50) AS LatencyP50,
  approx_percentile(OriginResponseTime, 0.90) AS LatencyP90,
  approx_percentile(OriginResponseTime, 0.99) AS LatencyP99
FROM log
WHERE OriginResponseTime IS NOT NULL
GROUP BY RequestPath
HAVING count(*) > 100
ORDER BY LatencyP99 DESC
LIMIT 20

3.1.3 告警规则示例

告警一，源站出现五百xx突然增多的情况，当错误占比超过百分之五的时候就会触发，能够迅速发觉源站存在异常。

* | SELECT
    count_if(OriginResponseStatus >= 500) * 100.0 / count(*) AS Origin5xxRate
  FROM log
  HAVING Origin5xxRate > 5

对了，有个告警2，是这样的，当高风险请求突然增加，次数超过100或者占比超过10%的时候，就会触发，然后还要识别潜在攻击，就是这样。

* | SELECT
    count_if(IsHighRisk = 1) AS HighRiskCount,
    count_if(IsHighRisk = 1) * 100.0 / count(*) AS HighRiskRate
  FROM log
  HAVING HighRiskCount > 100 OR HighRiskRate > 10

告警三：WAF拦截量突然增多，当拦截超过1000次或者独立攻击者超过50个的时候触发，能察觉到攻击的态势。

* | SELECT
    count_if(SecurityAction = 'block') AS BlockCount,
    approx_distinct(ClientFingerprint) AS UniqueAttackers
  FROM log
  HAVING BlockCount > 1000 OR UniqueAttackers > 50

3.2 成本对比

在此节当中，采用“能力对齐”这种方式来开展端到端 TCO 对比，其覆盖了 SLS 在该方案里所承担的完整闭环能力，其中包括数据传输，也就是 S3 导入，还有数据加工，即 SPL，以及存储与索引，随后是查询分析，接着是告警，最后是可视化，大约有 100 个仪表盘。为了使结论不因“只算存储/只算查询”而出现失真的情况，AWS 侧挑选了与之最为接近的 CloudWatch 一体化口径当作对标，此对标涵盖 Logs、Logs Insights、Dashboards、Alarms。

3.二点一的口径，以及具体参数，三点二点二呢，是单价来源的说明，再者三点二点三哟，是分能力的对齐，与计算。

1）数据传输 / 导入（把 S3 归档变为可检索数据）

有这么一种计费方式，它是按照写入的数据量来完成计费的，这种计费方式被应用于SLS，也就是Pay-by-ingested-data。

1 TB = 1,024 GB
20 TB/天 = 20,480 GB/天
月费用 = 20,480 GB/天 × 0.061 USD/GB × 30 天/月
      = 37,478.40 USD/月

公网的网络方面的费用，是从S3向SLS拉取时产生的，这个费用会计入到SLS方案的TCO当中。

说明：从 S3 拉取的是压缩对象，按“压缩后约为原始 1/10”估算网络出站流量
公网出站量（GB/天）= 20,480 GB/天 ÷ 10 = 2,048 GB/天
公网出站量（GB/月）= 2,048 GB/天 × 30 天/月 = 61,440 GB/月
按 AWS 口径：每月前 100 GB 公网出站免费 → 计费量 = 61,440 - 100 = 61,340 GB/月
分段计费示例（以 AWS 定价页 Data transfer 表格为准）：
- First 10 TB / Month：10,240 GB × 0.09 USD/GB = 921.60 USD
- Next 40 TB / Month：40,960 GB × 0.085 USD/GB = 3,481.60 USD
- Next 100 TB / Month： (61,340 - 51,200) GB = 10,140 GB × 0.07 USD/GB = 709.80 USD
月费用合计 = 921.60 + 3,481.60 + 709.80 = 5,113.00 USD/月

亚马逊网络服务（云观察日志摄取），这是一种服务，它涉及到云观察日志的摄取，属于亚马逊网络服务范畴。

月费用 = 20,480 GB/天 × 0.50 USD/GB × 30 天/月
      = 307,200.00 USD/月

2）数据加工（过滤 / 清洗 / 分发）

3）存储（14 天保留）

稳态存储量（14 天保留）= 20,480 GB/天 × 14 天 = 286,720 GB
月费用 = 286,720 GB × 0.03 USD/(GB×month)
      = 8,601.60 USD/月

4）查询分析

100 TB/天 × 1,024 GB/TB = 102,400 GB/天
月费用 = 102,400 GB/天 × 0.005 USD/GB × 30 天/月
      = 15,360.00 USD/月

5）告警

月费用 = 20 个告警 × 0.10 USD/个/月
      = 2.00 USD/月

6）仪表盘可视化（约 100 个 Dashboard）

月费用 = 100 个 Dashboard × 3.00 USD/个/月
      = 300.00 USD/月

3.2.4 费用汇总

SLS（月度）≈ 37,478.40（写入）+ 5,113.00（S3 公网出站）= 42,591.40 USD/月
AWS（月度）= 307,200.00（ingestion）
          + 8,601.60（storage）
          + 15,360.00（Logs Insights scanned）
          + 2.00（Alarms）
          + 300.00（Dashboards）
          = 331,463.60 USD/月

因此，在本节口径与参数下：

月度节省金额 = 331,463.60 - 42,591.40
            = 288,872.20 USD/月
成本降低 = 1 - (SLS / AWS)
        = 1 - (42,591.40 / 331,463.60)
        ≈ 87.15%

3.2.5 结论

日志文件一般是经过压缩然后归档的，本文是按照压缩比为10比1，也就是压缩之后大概是原始大小的十分之一来进行估算的。在这样的假设之下，SLS方案从端到端的角度来看，相较AWS（CloudWatch一体化），TCO降低了百分之八十七点一五；与此同时呢，因为SLS根据写入量来计费，30天的存储是免费的，这一节是按照14天来计算的，就相当于额外得到了16天的免费存储。

除了这些之外，SLS的数据加工能力，在这种计费模式之下，是不用另外计费的，其投递与告警等能力同样如此，Dashboard也不会按照“个数”来单独收取费用；然而在AWS那边常常是要为Dashboards、Alarms以及与之配套的ETL、投递组件分别进行计费的，这就表明用户能够免费获取到更多的额外能力。

总结展望

数据迁移时，跨云或者跨境传输的网络质量不能被忽略，费用同样不可以无视，为此，我们造就出致使云/跨境传输费用减少的能力，借助CloudFront，供用户挑选。

与此同时，在后续阶段，我们还进一步拓展了 GCP/Azure 的数据导入工作，以此来达成支持多云数据进行统一观测的目的。

参考：

OpenText SAST (Fortify) 26.1 (macOS, Linux, Windows) - 静态应用安全测试

Mon, 06 Apr 2026 14:30:25 +0800

OpenText的静态应用安全测试（也就是Fortify），版本为26.1，适用于macOS、Linux以及Windows系统的，关于静态应用安全测试的相关内容。

OpenText SAST，之前被称作Fortify SCA，它是一款用于代码漏洞扫描的工具，可进行静态代码测试，还能开展代码安全分析。

可以去访问原文链接，也就是那个https://sysin.org/blog/opentext-sast/ ，去查看全新最新版，这可是原创的作品哟，要是进行转载的话，一定要保留好出处呢。

作者主页：sysin.org

OpenText 静态应用安全测试（Fortify）

以行业领先的准确性及早发现并修复安全问题

OpenText SAST 26.1 新增功能

关于 OpenTextTM 静态应用安全测试（SAST）

现阶段，OpenTextTM SAST（也就是 Fortify 静态代码分析器），已经对 44+ 种语言予以支持，覆盖有 1524 种漏洞类别，并且涉及到超过一百万个 Api。

OpenText SAST 26.1 有哪些新特性？

OpenText SAST 26.1被宣布推出，此次发布着重聚焦于性能，聚焦于可扩展性，还聚焦于广泛的语言支持，本次更新的核心是全新的AI Analyzer，它是一项新一代能力，能显著加快新语言支持的开发速度，让安全团队能够以前所未有的敏捷性跟上现代开发技术栈的发展。

引入 AI Analyzer：批量解锁新语言支持

全新的AI Analyzer让组织能够接入自身所拥有的大语言模型（LLM），进而能够快速地创建以及调优静态分析规则。这表明可以更迅速地支持新的或者特定领域的语言，而不用等着传统SAST的完整支持周期。

借着 AI Analyzer 的助力，SAST 26.1 当下已经对 12 种编程语言予以支持：

AI 驱动的语言支持：

涵盖多种种类的语言里，AI Analyzer针对每种进行语言覆盖，有着20+的漏洞类别，其中包含注入类漏洞、不安全配置、加密方面的误用、不安全反序列化、凭证管理所出现的问题等，主流框架（诸如Ruby-on-Rails）在开箱的时候就能够提供支持。

引擎其他更新

OpenText SAST 26.1 当中，还涵盖了重要的兼容性方面的更新，目的在于确保工具链能够维持现代化以及稳定性：

这些更新得以保证，开发者能够运用最新工具链，与此同时，还能从SAST 26.1的增强能力之中获取益处。

安全内容更新

研究团队更新了多个领域，不是仅仅靠AI Analyzer扩展语言支持这样，是除此之外进行的动作，有更新，在多个领域，进行了更新。

AI & ML 内容更新：

以下这里的库，已然经过更新，其目的在于确保能够与这些处于快速发展状态的领域当中的至新最的 API 变更维持兼容兼容的状态，是这样情况的哟：

加密更新：

顺着在25.4里开展的工作继续下去，为了助力组织辨别出那些不具备抵抗后量子密码也就是PQC攻击能力的代码，在使用Node.js的时候，26.1增加了相关支持，在使用Java的Bouncy Castle时，同样增加了相关支持。

报告更新：

对于要做到持续优先去处理针对其所在行业而言最为关键重要核心的那些问题的组织来讲，OpenText SAST 26.1之中的安全相关内容此刻已然被映射到了最新的标准情况上以及最优秀的实践做法方面。

其他重要改进与差异

误报减少及其他检测优化：

系统要求

这里列出操作系统部分，详细描述参看附带的文档。

macOS

Linux

Windows

成都高防机柜租用防攻击全指南服务标准及靠谱服务商挑选攻略

Mon, 06 Apr 2026 14:30:13 +0800

服务商要拥有IDC经营许可证，要有网络安全等级保护三级备案，其所有防护操作得符合《网络安全法》相关要求，且用户数据隐私保障体系要完善，以此来避免出现数据泄露风险。

想要挑选出靠谱的服务商，可从三个维度着手进行判断，首先去看防护资源的储备情况，究竟有没有自建的高防机房，以及是否具备足够的带宽储备，其次查看行业案例，也就是有没有同行业的防护服务经验，最后审视服务SLA承诺，看其是否拥有赔付条款来保障用户的权益。

主营IDC数据中心、服务器托管、机柜租用、带宽接入的极云科技，在业内口碑比较好，其成都本地高防机房具备T级防护带宽，防护策略能够灵活定制，已经给超过300家成都本地企业提供了稳定的高防服务，要是有需求可以访问官网去了解详细情况。

要是对于防护能力有着较高要求，那么建议优先去选择支持免费测试的服务商，能够模拟真实攻击场景，以此测试防护效果，然后再决定是否进行合作，防止后续出现防护不达其位的问题。

对于企业而言，能够依据业务类型以及历史攻击数据，来评估所需的防护量级，可以这么说，针对电商、游戏、金融类业务，建议选择防护等级在500G以上的，而普通官网类业务，则能够选择300G基础防护，这么做是为了避免出现资源浪费的情况。

当签订服务协议之际，要明确防护范围，以及故障响应时间，还有赔付标准等核心条款，以防止后续出现纠纷之时没有维权依据，针对那些不知道怎么梳理条款的企业而言，能够拨打电话去咨询极云科技的专业顾问从而获取免费指导。

建议企业，每三个月开展一回攻击模拟测试，检验防护策略的有效程度，及时去调整防护规则，用以应对新型攻击手段，确保业务一整年都不会出现中断运行情况。

从整体上来进行观察，在二零二六年的时候，成都地区的高防机柜租赁用于防范攻击的一些服务体系已然是极为成熟，如果企业能够明确自身所具备的需求，并且依据标准去挑选服务商，那么就能够获取到稳定且可靠的防护成效，从而为线上业务的发展筑牢安全方面的屏障。

Claude Code 的工具系统是怎么设计的：一文读懂 Agent 为什么不只是会调函数

Mon, 06 Apr 2026 14:28:49 +0800

要是你已然可以去调用大模型，而且还做过最为基础的那种“让模型挑选工具并且发起相应调用”的小型实验，紧接着很容易遭遇到一种落差：

模型已然能够“调用工具”，然而系统却依旧不太好似那种真正负责将任务予以交付的 agent。

有可能它会去查找资料，会去阅读文件，也会去运行某些命令，然而一旦任务稍微复杂那么一点儿，就会出现如下这些问题：

这段话表明，实际存在困难的关键之处，向来都不是只是单纯地为模型连接几个函数，而是在于究竟该如何将工具予以转化，使其成为一套能够实现可调度、可进行约束的执行系统。

这篇文章既不讲述工具列表，也不制作API说明书，我们转换到一个对于agent开发者而言更为适配的视角，Claude Code究竟是怎样将工具构建成runtime的，以及这一套设计为何具备值得借鉴之处。

1. 首先，去构建起一个正确的心智模型，工具并非函数表，而是runtime合同，这一点要明确。

很多新人第一次做 agent，会先写出这样一份工具表：

async function readFile(filePath) {
  return fs.readFile(filePath, 'utf8');
}
const tools = {
  readFile,
  editFile,
  searchWeb,
  runShell,
};

这肯定是能够跑起来的，然而它仅仅是解决了一个极为狭窄的问题，那就是模型可不可以依照要求发起一次工具调用。

实际困难之处并非在于“是否具备调的能力”，而是在于此次调用能否经受校验，能否受到约束，能否得以执行，以及能否将结果平稳地承接回来，以备后续推理所用。

如果将这般的小实验朝着“能够稳定地达成任务”而去进行推进，紧接着就会遭遇到另外一组的问题。在此处暂且不着急去做出结论，首先应当让问题完全地呈现出来以供查看。

模型所看到的工具名字，以及描述，还有输入结构，究竟是由谁定义的？一个工具处在当前会话之中，是否应当暴露，可不可以动态下线？当模型生成的参数格式不正确、值不具有合法性时，由谁来进行兜底？此次调用是属于只读、写入，还是潜在破坏性操作？调用之前，是否需要进行权限判断、hook（流程前后插入的额外逻辑）、审计或者用户确认？两个工具能否并发，并非由“是否异步”来决定，那么应当由什么来决定？工具执行完毕之后，结果应当如何回流，模型下一轮才能够看得懂？UI 展示给用户的内容，为什么不能直接等于工具内部返回值？

这里暂且将问题压制住，不急于去进行解释。接下来的几章里，我们依照这条已然存在的问题链顺从而下：首先去查看一个工具究竟是怎样被定义出来的，然后再来审视它是以何种方式进入会话之中的，又是怎样被执行的，以及如何参与并发进程的，最后再回转到文章起始部分所提及的那些问题上去。

2. 怎去写一个工具，从Tool而实施抽象进展到readFile的实现呢？

Claude Code的起始步骤，并非径直且零散地达成一堆工具，而是先行界定统一的Tool 合同，你能够将其大致理解成如下这般。

type Tool = {
  name: string;
  inputSchema: Schema;
  outputSchema: Schema;
  description(): Promise;
  prompt(): Promise;
  validateInput(input): ValidationResult;
  checkPermissions(input, context): PermissionResult;
  isReadOnly(input): boolean;
  isConcurrencySafe(input): boolean;
  call(input, context): Promise;
  // 概念层：把工具内部结果整理成“可回写”的标准结果
  formatResult?(result): ToolResult;
  // 实现层：把结果映射成真正写入消息流的 tool_result block 参数
  mapToolResultToToolResultBlockParam(
    result,
    toolUseId,
  ): ToolResultBlockParam;
};

这里进行一层补充说明，以此来防止将两个处于不同层次的接口视作冲突，上面所提到的formatResult是为了有助于理解而被抽象出来的“结果格式化”能力，当落实到Claude Code的实际实现过程中，更为常见的是更为具体的mapToolResultToToolResultBlockParam(result, toolUseId)。它携带的 toolUseId 比 formatResult 多一个，返回的并非泛化的 ToolResult，而是 tool_result block 参数，此参数能够直接写回会话消息流。下面当进入结果回写时，我们按照这个更贴近实现的名字统一展开。

第一眼瞅见这段接口，极易被字段数量给吓到。更为得当的读法并非逐个去背字段，而是先将它拆分成3组：

2.1 模型接口：告诉模型“这个工具叫什么、怎么用”

这一组字段决定的是，模型眼里看到的工具协议是什么：

它们能被你理解成是“给模型看的那个侧面”，名字、描述以及输入结构让人搞不清楚，模型连怎样发起一回稳定调用都没办法去做到。

2.2 runtime 控制：告诉系统“这次调用该怎么被约束”

这一组字段决定的是，runtime 要怎么管理这次调用：

这儿的关键并非是“可不可以进行调用”，而是在于“系统应不应该予以放行”，以及“应当怎样去调度”，还有“能否实现并发”。

2.3 执行与结果回写：工具做完以后，结果怎么回到会话里

这组需要处理的问题相当具体，工具运行 end 之后，结果不可以仅仅停留在程序范围之内，还必须返回至会话之中，变成模型下一轮切实能够看到的上下文。

对应到代码里，通常会分成两步：

于Claude Code之中，工具执行完毕并非终点，对于agent来讲，结果还需被稳定地写回到会话，如此后续的推理方可接上。

这也是为什么这里要把“执行”和“结果回写”分开看。

如果用伪代码表示，大概是这样：

const result = await tool.call(input, context);
// 比如：工具内部先返回
// { content, filePath, lineCount }
const toolResult = tool.mapToolResultToToolResultBlockParam(result, toolUseId);
// 然后整理成会话里真正要写回的结构
// { type: 'tool_result', tool_use_id: 'xxx', content: '...' }

为什么不使得 call() 径直返回最终会写回到会话里的结果呢？是由于这两层所处理的是两类不一样的问题。

分开之后，工具的内部能够留存自身最为自然的数据结构，然而整个系统在写回到会话之际，依旧能够维持统一的格式。

若缺失这一步骤，极易出现一种颇为典型的情形，程序中分明已获取到结果，然而模型下一轮却仿若未曾看见，原因在于结果未被整理成其真正能够继续读取的会话内容。

所以，这一组能力，实际上仅仅是在处理两件事情，其一为，工具究竟该如何切实地执行，其二是，在执行完毕之后，结果要怎样回归到会话当中，进而成为后续对话仍能够持续运用的上下文。

2.4 buildTool：统一创建工具，并补齐默认行为

源码当中存在着一个特别值得去借鉴的微小设计，那就是buildTool，它并非属于语法糖，而是通过使用默认值，强制性地让大家去遵循统一的安全基线：

const TOOL_DEFAULTS = {
  isEnabled: () => true,
  isConcurrencySafe: () => false,
  isReadOnly: () => false,
  isDestructive: () => false,
  checkPermissions: input =>
    Promise.resolve({ behavior: 'allow', updatedInput: input }),
};

在这里，最为关键的一点在于，与安全相关的方面，默认秉持保守态度，而针对便利性的相关内容，默认进行补齐。你能够将 buildTool 理解为这样一个函数，它能够统一创建工具，并且顺便将默认行为予以补齐。如此一来，每一个官方工具在进入系统之前，都会首先遵循同一套基础规则，而非各自编写各自的。

2.5 用 readFile 看一个工具是怎么落地的

有了这般抽象之后，再去看 readFile 的话，就会更加容易理解了。Claude Code 当中的 FileReadTool 并非是 fs.readFile 的那种简单的薄封装，而是一个完整的工具。

export const FileReadTool = buildTool({
  name: FILE_READ_TOOL_NAME,
  maxResultSizeChars: Infinity,
  strict: true,
  userFacingName,
  isConcurrencySafe() {
    return true;
  },
  isReadOnly() {
    return true;
  },
  async checkPermissions(input, context) {
    return checkReadPermissionForTool(
      FileReadTool,
      input,
      context.getAppState().toolPermissionContext,
    );
  },
  async validateInput({ file_path, pages }, toolUseContext) {
    // 参数值校验
  },
  async call(input, context) {
    const filePath = resolveFilePath(input.file_path);
    const content = await readFile(filePath, 'utf8');
    return {
      filePath,
      content,
      lineCount: content.split('\n').length,
    };
  },
});

这个例子能把 Tool 合同讲得非常具体。

其一，它首先表明自身是具备只读特性、能够进行并发操作的。这意味着，并发所采用的策略并非由执行器凭借主观臆断得出的，而是由工具自身予以声明的。

第二，它存在着单独的 checkPermissions。读取文件这件事看上去风险是比较低的然，而却依旧是要遵循文件系统权限规则的，并非是由于“仅仅只是 Read”便能够绕过 runtime。

其三，它存在自身的validateInput。即便模型清楚file_path、offset、limit这些字段，也并不意味着它必定会给出合法的值。举例来说，像PDF的pages范围，以及偏移参数的边界，均需要工具自行承担责任。

第四，它的call当中所处理的内容远远不止是文本读取这一方面，在源码里面能够看到这样一些逻辑。

所以，从runtime的角度去看，readFile的原本职责并非是“把磁盘里的内容取出来”，而是“将受到约束、能够进行解释、还可以持续推理的上下文安全地注入到会话当中”。

行进至此处，再度回首去看标题之中的“runtime 合同”，它起码已然不单单只是一种比喻了，只要你着手郑重对待 schema，而且处理权限问题，以及考量只读性，还有关注并发性，同时处理结果映射，那么工具便不再是一个单纯的裸函数了。

即换个说法来讲，这一章节切实所回应的内容是，究竟是谁来对工具协议予以定义，当参数不符合规定的时候又是谁来承担责任，以及读写风险和权限检查具体应当放置在哪一个层面。Claude Code给出的答案并非是“调度层进行临时判断”，而是将这些能力直接构建到Tool合同之中。

3. 工具注册

对工具完成定义之后，并不意味着模型马上就能够看见它，Claude Code存在着一层专门的注册逻辑，用以回答另一个常常被忽视的问题：

当前这一轮，到底该给模型开放哪些能力？

在getAllBaseTools()当中是基础入口，它首先组出一套内建工具集合，这套集合是“理论上可用”的。

export function getAllBaseTools(): Tools {
  return [BashTool, FileReadTool, FileEditTool, WebFetchTool, ...extraTools];
}

然而，真正用于当下这次会话的，并非这那份静态列表，而是要对getTools(permissionContext)进行再次过滤：

export const getTools = (permissionContext: ToolPermissionContext): Tools => {
  if (isEnvTruthy(process.env.CLAUDE_CODE_SIMPLE)) {
    return [BashTool, FileReadTool, FileEditTool];
  }
  let allowedTools = filterToolsByDenyRules(
    getAllBaseTools(),
    permissionContext,
  );
  return allowedTools.filter(tool => tool.isEnabled());
};

这个注册链路至少做了三件事。

其一，要分辨清楚“已然达成的状态”和“已然显现出来的状况”之间的不同之处，工具被书写于代码当中，然而这并不意味着在当前这一轮就应当让模型去看到它。

其次，将环境以及模式引入进来。在simple模式的情形下，系统会主动地退化为极小的工具集，并非是把全部能力都向模型进行开放。

第三，将deny rules以及isEnabled()当作注册阶段的一部分，并非等到模型调用之际才予以拒绝，如此这般去做所具备的意义颇为重大，原因在于其削减了模型的决策噪音，并且缩小了高风险能力的暴露范围。

这同样是致使 Claude Code 的工具系统更趋近于“能力管理系统”，而非一个函数目录的缘由。注册层所要处理的并非“还有哪些函数尚未挂上”，而是“在当下这一轮对话之中，哪些能力应当被模型所察觉”。

所以，这一章想要回答的问题，实际上是颇为简单的：哪怕一个工具已然写妥，为何在这一回的会话当中，依然有可能不应将其暴露给模型。Claude Code的举措乃是，把“实现”以及“暴露”清晰地划分成两个层次，先是具备能力，随后再去判定当下是否要予以公开。

4. 工具的生命周期

模型产出一个 tool_use 之后，Claude Code 并非马上 tool.call()，它有着一条明确分层的生命周期，有着一条明确分层的生命周期。

依据源码当中的runToolUse以及checkPermissionsAndCallTool去进行压缩，大体上是如下这般的链条：

flowchart TD
    A["模型产出 tool_use"] --> B["按 name 找到 Tool"]
    B --> C["按输入结构先做基础解析"]
    C --> D["validateInput"]
    D --> E["PreToolUse hooks"]
    E --> F["权限决策"]
    F --> G["tool.call"]
    G --> H["整理成标准化结果"]
    H --> I["PostToolUse hooks"]
    I --> J["写回会话，继续推理"]

如果只看核心代码，味道是这样的：

// 先按输入结构做基础解析
const parsedInput = parseInputBySchema(tool.inputSchema, input)
// 再做更细的参数校验
const isValidCall = await tool.validateInput?.(parsedInput.data, toolUseContext)
let processedInput = isValidCall.updatedInput ?? parsedInput.data
let hookPermissionResult
// 运行前置 hooks：
// 1. 可能补充消息
// 2. 可能追加额外上下文
// 3. 可能改写输入
// 4. 也可能直接阻断执行
for await (const result of runPreToolUseHooks(
  toolUseContext,
  tool,
  processedInput,
  toolUseID,
  messageId,
  requestId,
  mcpServerType,
  mcpServerBaseUrl,
)) {
  // 根据 hook 返回的类型，更新输入、记录消息或中止执行
}
// 综合 hook 和权限系统的结果，决定这次调用能不能继续
const permissionDecision = await resolveHookPermissionDecision(...)
// 真正执行工具
const result = await tool.call(processedInput, context, canUseTool, assistantMessage)
// 把工具内部结果整理成会话里统一的返回格式
const toolResultBlock = formatToolResult(result.data, toolUseID)
// 运行后置 hooks，做补充处理
for await (const hookResult of runPostToolUseHooks(tool, result, context)) {
  // hook 可以追加消息、记录信息，或补充处理结果
}

这段流程可以先按 4 步来理解。

起始的率先步骤，是着手处理输入，系统会先行依据输入结构开展基础解析作业，之后再交付给validateInput去施行更为精细的参数校验工作，前者更近似于“字段类型是否正确”，后者更类似于“字段值能否如此应用”。

第二步，处理执行之前的控制逻辑，PreToolUse hooks 会在真正执行前头跑一回，它们能够补充消息，追加额外上下文，改写输入之际，甚至直接把这次调用给阻断掉，跟着，权限系统会依据当前规则决意这次工具调用可不可以继续进行呢。

第三步，切实去执行那款工具。直至抵达 tool.call(...)处，系统方才开始着手进行此次调用实际所要做的各类事宜。诸如读取文件，并对文件予以修改。或是执行命令，以及访问外部具备的能力等。

第四个步骤，要将结果书写回到会话之中。tool.call(...) 所返回的常常依旧是工具内部更便于进行处理的数据，系统还需要再次把它整理成为统一的结果格式，接着写回到会话里头。唯有如此，模型在下一轮的时候才能够继续读取到这次调用切实产生了什么。

就是第四步，在这儿是最容易被忽视不见了的。好多的系统会把“工具执行成功”当作是结束了，然而对于agent来讲，这样可还不成。只有工具结果重新进入会话，才能够变成后续推理真正可以用得上的上下文呢。

因此，于Claude Code之中，工具结果首要服务的是后续推理，其次才是界面展示，举例而言， FileReadTool在界面里或许仅仅显示“读取了多少行”，然而写回会话的结果会带有真正的文件内容、行号以及必要提醒，这两层特意分开，目的在于同时服务系统推理与交互界面。

要是回到文章起始处的那个问题，于这一章节切实补上的，乃是工具调用其间那条最为容易遭受忽略的主链路，参数验校放置于何处，权限以及hook插在啥位置，工具得出的结果又是怎样再度回归到下一轮的推理当中的。

5. 工具并行相关，并发策略

另外一个极易被搞砸的地方是工具并发，好多系统默认只要能async那就进行并发，Claude Code并非是这样的思路。

与此处紧密相关的一个极为关键的要点在于：并发并非毫无缘由地突然产生，并非是开发者在处理业务的代码之中硬性设定“这两个工具同时运行”。更为普遍的情形是，模型于一轮操作里给出了多个工具调用指令，执行器继而进一步去判定这些被给出的调用指令是否能够并行执行。

更接近真实输出的形态，大概像这样：

{
  role: 'assistant',
  content: [
    {
      type: 'tool_use',
      id: 'toolu_01',
      name: 'Read',
      input: { file_path: 'src/a.ts' },
    },
    {
      type: 'tool_use',
      id: 'toolu_02',
      name: 'Read',
      input: { file_path: 'src/b.ts' },
    },
  ],
}

换言之，模型在这一轮并非仅给出单一调用，而是一次性给出了两个读取请求，到了此步骤，执行器才会进一步判断，这两个Read能否一同运行，抑或是必须排队执行。

也就是说，这里有两层分工：

真正对并发能否成立起到决定作用的，并非模型对于并发有没有意愿，而是这般工具在语义层面上是不是准许并发去施行。

StreamingToolExecutor当中的核心判断极为简单明了，毫无复杂曲折之处：。

private canExecuteTool(isConcurrencySafe: boolean): boolean {
  const executingTools = this.tools.filter(t => t.status === 'executing')
  return (
    executingTools.length === 0 ||
    (isConcurrencySafe && executingTools.every(t => t.isConcurrencySafe))
  )
}

它真正关心的是：这次调用在语义上是否并发安全。

再结合工具定义里的声明，你就能看懂这套策略：

这背后所蕴含的价值，并非是“更趋于保守”这种情况，而是要达成这样一种结果，即让并发策略与工具语义形成绑定关系，并非是与技术实现建立绑定关系。

由于 agent 的工具并非纯函数，它们对文件系统、终端、外部服务以及会话状态进行操作，只要牵涉到副作用，那么并发问题并非吞吐问题，而是一致性问题。

Claude Code 在执行器里还做了两件很实用的事：

结语

回首去看，文章起始部分的那几个具有典型特征的问题，实际上都能够在这条主要的线索之上寻觅到所处的位置。

工具为何不该仅仅是函数表，与之对应的是统一 Tool 合同；工具为何不能进行全量暴露，与之对应的是注册层；工具为何不能在拿到名字后就直接被执行，与之对应的是完整生命周期域在；工具如果不能盲目并发，与之对应的是语义驱动的并发策略。

Cleaude Code的工具系统是值得去进行借鉴的，并非是因为其工具数量众多，而是由于它将工具放置到了runtime的核心位置。对于刚刚从“能调LLM”朝着“能做agent”迈进的开发者而言，这样的转变是尤为关键的，当你开始把工具当作合同、能力入口、执行对象以及结果回流节点来开展设计的时候，你才算是真正进入到了agent runtime的实现阶段。

PI Event Frame 到 AI 时代，这个问题终于被重新看见了｜TDengine IDMP 的事件化启示

Mon, 06 Apr 2026 14:18:38 +0800

工业系统不间断地生成时间序列数据，每一秒，传感器都在记载温度、压力、流量、振动等各类信号，在过去几十年间，这始终是工业数据系统以及工业实时数据库的根基：收集信号，高效储存，并借由可视化觉察它们随时间的变动。

这种方式是有效的，但它存在一个根本性的局限。

仅时间当作序列排列的数据，仅仅能够告知我们“出现或产生了改变”，然而却没有办法去告知我们“究竟发生了哪些具体的事情”。

于趋势图之上，或许能够见到一回压力蓦地提升，然而那却没办法阐释此番变化究竟发生在开机的这个阶段，还是稳定运行之阶段，又或者是不是处于异常工况之下。温度的降低，可能是正常的调节情形，也有可能是故障的初期信号。要是缺少工业方面的上下文，不同的工程师面对同一小段数据，极有可能得出全然不一样的判断。这便是数据跟理解之间所存在的鸿沟。

工程师思考问题并非依据“时序数据”，也不只是按照“趋势”来进行思考，他们反而更倾向于依据“事件”去领会系统情况，像开机、停机、批次运行、工况切换、异常发生这些情况，这些才属于工业运行的基本单位，同时也是最具意义的分析对象。

由时序数据朝着事件转变，工业实时数据库究竟达成了什么正确之事，然而现代数据平台又遗漏了什么呢？

数据跟理解二者之间存在的鸿沟，并非是近几年才冒出来的状况，也并非行业没察觉到这个状况。实际上，工业数据范畴早就给出了一个特重要的答案。

PI System 提出了 Event Frame 的概念，该概念从根本上改变了工程师使用时间序列数据的方式，它不再把数据视为无穷无尽的数值流，而是允许工程师定义有明确起止时间的“有意义区间”，像开机、停机、批次运行或者异常状态，并且将这些事件与设备、属性以及上下文关联起来。

这属于一种极其关键的进步，它认可工业运行并非单纯是信号的简单叠加，而是由一系列具备明确意义的事件所组成，它促使数据模型开始靠近工程师的思维模式，还使得工程师能够从“查看数据”转变为“理解运行进程”，对众多用户而言，Event Frame是PI System里极具价值的能力之中的一个。

从这个特定角度去看，那以 PI 作为显著代表的工业实时数据库，并非是对这个问题有所漠视，相反地，在极为早期的时候就给予了一个相当正确的建模导向，然而，真正能够引发人们去进行深入思考的却是后续所发生的那些事情。

前行至行业朝着现代数据基础设施逐步演进之时，诸如 Snowflake、Databricks 这般的系统于存储、计算以及扩展性这些方面达成了极大突破，它们能够去处理数量庞大的数据，给予复杂分析以支持，并且与现代数据生态系统达成高度集成。

但在这个过程中，一个关键能力被忽略了。

这些系统的核心抽象依旧是表、文件以及通用的数据处理模型，它们并未提供像 Event Frame 那样的原生概念，系统里不存在“开机”“批次”“异常”这类第一类实体，工程师只能借助 SQL、数据管道或者自定义逻辑去重构这些语义。

这就带来了一个明显的错位。

基础设施呈现出更为强大的态势，然而，在操作层面上，数据的可理解性却出现了下降，数据能够更轻易地被进行存储以及计算，可是，对于工程师切实关切的问题：究竟发生了什么？从何时起始？与其他类似情形相比较会怎样？要做出回答则变得更为困难了。

所以，就算有着强大并且能够扩展的基础设施，然而真正以事件当作核心的分析依旧是很难达成的。问题并非在于计算能力方面，而是在于缺少一个以操作语义作为核心的数据模型。

事件建模与事件分析之间的鸿沟

即便 Event Frame 是个极为强大的概念，然而它于实际系统里的落地形式，亦透露出了一些限制之处。

在PI System里，Event Frame是于Asset Framework中被定义以及管理的，它能够把事件跟设备、时间区间还有相关属性关联起来，给工业操作行为提供了结构化的建模方式，这一能力相当重要，它让工程师能够明确地定义出像批次、开停机过程或者异常工况等关键运行阶段。

然而，当真正进入“分析”环节时，情况就开始变得分散。

于多数情形之下，工程师借助 PI Vision 等工具，于选定的时间窗口当中查看数据变化。此项方式适用于基础的排查及可视化，然而对于更深层次的事件分析而言其能力是有限的。

于实际工业场景里，诸多关键分析根本上皆是围绕“事件”来开展的。就拿批次生产来讲，工程师常常得对多个批次予以对比，以此去明白什么才是“好样的运行状态”。他们会把不同批次依据开始时间对齐，进而生成所谓的“黄金曲线（golden profile）”，随后剖析某一个异常批次在各个阶段究竟是怎样偏离这一基准的。这般分析对于质量优化、根因定位以及工艺改进是至关重要的。

这些批次借助 Event Frame 得以清晰分明地被定义且组织妥当，然而，真正进行包含时间对齐、实行归一化处理、展开统计对比以及开展模式识别的分析过程，在核心系统里并未获得深入的有力支持。所以呀，好多企业不得不引入 Seeq、TrendMiner 等专门的分析工具，以此来完成这些围绕事件展开的分析任务。

这实际上揭示了一个非常关键的架构问题。

事件的一个情况是建模存在着，然而事件分析却不曾和它深度融合起来。事件被进行定义这一动作完成了，可它并未成为分析的核心单位哟。工程师在由事件里提取洞察的时候，常常需要跨越多个系统，去搬运数据，并且在不同工具之间反复构建分析逻辑呢。

倘若事件属于工业运行的基本单元，那么它同样应当成为分析的基本单元。

从资产结构到运行行为

上一篇讨论“以资产为核心的数据建模”时，我们关注的是结构，即数据围绕设备和系统怎样去组织，这把“系统是什么”的问题给解决了。

而事件建模，则是在此基础上引入“行为”。

要是讲资产描绘的是系统自身，那事件描绘的便是系统于时间范畴里的运行进程，开机进程、批次运转、异常状况，这些并非静态势结构所能呈现的内容，而是运行举动的展现。

两者结合，才能构成对工业系统更完整的表达。

以资产为核心的建模定义结构。

以事件为核心的建模定义行为。

若不存在事件，数据便是连续性的数值流，依旧得通过人工予以解释，而当有了事件，系统自身便已然开始拥有表达运行过程的能力。

为什么在 AI 时代，事件变得更加重要

在 AI 时代，事件的重要性被进一步放大。

存在着许多直接作用于时间序列数据的AI应用，然而，这样的方式存在着天然的局限，原始信号既缺乏清晰的边界，又缺乏上下文的信息，要是不知道数据所处的运行状态，那么很难正确理解其中的模式。

事件为 AI 提供了一种天然的结构。

它把数据划分成有意义的单元，致使系统能够针对相似事件作出对比，依据事件起点让数据达成对齐，剖析正常与异常之间存在的差异。更为关键的是，它给予了AI理解数据所必备的上下文。

倘若有一个AI模型，它不清楚设备究竟处于开机状态，还是停机状态，亦或是稳定运行状态，只是单纯地去分析振动数据，那么就极容易得出错误的结论。然而要是在有着清晰定义的事件范围之内展开分析，便能够明显提高结果的准确性以及可解释性。

在不存在事件的情形下，AI所见到的是数据，而当有了事件之后，AI才能够对行为予以理解。

走向以事件为核心的工业数据底座

想要切实发挥工业数据的价值，事件得成为工业数据底座的一部分，而不该只是附加于上层的功能。正因如此，如今的工业数据平台不能光停留在“存储 + 计算”层面，而得同时拥有事件建模、事件分析以及AI理解能力。就拿 TDengine IDMP 来说，它现今正将数据目录，以及数据标准化、数据情景化，还有事件、分析与 AI 能力，放置于同一个平台框架之内，从而使得事件不再仅仅是依附于时序数据的标志，转而开始变成能贯穿数据治理、业务分析以及智能决策的关键对象。像这样的平台方向，才会更加贴近 AI 时代工业数据底座实际该有的样子。

这意味着，事件的定义，不应分散在各异系统内，存储亦不应如此，分析同样不应如此，而应与时间序列数据一道，还应与资产模型一道，共同构成统一的工业数据平台基础。

PI System所提出的Event Frame，是极为关键的一个起始点。然而在AI时代，此项能力得要进一步予以提升，从“重要功能”转变为“基础能力”。

事件，它并不是仅仅作为分析的一种方式存在，相反，它是构建智能工业系统时，所绝对必需不可或缺，的组成部分。

时序数据描述变化，资产描述结构，事件描述行为。

这三者相互结合之后，才能够真正地做到对于工业运行的理解，也才能够去支撑那下一代的、以AI作为驱动力量的工业系统。

成都整机机柜租用电信机房收费标准及靠谱服务商选型全指南

Mon, 06 Apr 2026 14:13:50 +0800

“东数西算”工程进入深度落地的这段时间里，到了2026年，成都身为西部算力枢纽的核心承载节点，算力部署需求同2025年相比增长了47% ，在成都，整机机柜租用电信机房的需求占比达到了62% ，这使得它成为政企、金融、互联网等行业算力部署时首选的资源。本文会从价值维度、收费标准、选型方法等方面着手，展开系统的梳理，给专业人士提供参考。

成都电信所拥有的自营机房，全都符合国家所规定的A级机房标准，其中多数都达到了Tier3+以及更高的等级，具备着99.99%的uptime保障，在电力冗余方面采用的是N+1甚至是2N配置，其网络出口直接连接国家骨干网，在省内进行访问时延迟低至1ms以内，适合用于对稳定性有着极高要求的核心业务、涉密业务的部署。

较之于单台服务器托管，整机机柜租用能够达成资源统一管控，削减单U托管的边际成本，适宜于算力需求在10U以上的企业用户。与此同时，能够依据需求定制电力、带宽、安全防护配置，去适配人工智能训练、大数据分析、分布式存储等各异业务场景的需求。

在二零二六年，成都地区的整机机柜租用电信机房，其最新收费标准主要是由四大模块来构成，具体的情况表现为，如下所示：

基础机柜的费用，是按照42U标准机柜来进行核算的，其中涵盖了基础机位，设有默认的5个公网IP，还有10A的基础电力配额。

超额的电力费用，是指超出基础电力配额的那一部分，它依据 1.2 至 1.8 元每 A 每天的标准来进行阶梯式计费，对于那些高电需求的客户而言，他们能够申请打包价。

带宽费用，是按照独享带宽来进行核算的，其中，100M电信独享带宽的月费处于800元到1200元这个范围，而1G独享带宽的月费则是7000元到10000元。

费用为增值服务，其中涵盖DDoS防护服务，还有远程运维服务，以及7*24小时驻场支持服务等，这些服务是按需单独进行计费的。

众多用户在意成都整机机柜租用电信机房一个月的费用是多少，从2026年市场公开报价可知，基础配置的机柜，也就是42U标准机柜、10A电力、5个IP、100M独享带宽的机柜，其月费区间为3500 - 5500元，而高电配置的机柜，即20A以上电力、1G以上带宽的机柜，其月费可达8000 - 15000元。

收费差异主要受到四大变量的影响，其一为机房等级，Tier4机房的报价比Tier3机房高出大概30%，其二是机房区位，天府新区算力枢纽节点机房的报价比主城区老机房高出约15%，其三是采购周期，年付、3年付能够享受15%至30%的优惠，其四是采购量级，10柜以上的集团客户能够享受定制化折扣。

三、成都整机机柜租用电信机房哪家服务商靠谱的选型维度

有靠谱资质的服务商，要拥有 IDC 经营许可证，还要有 ISP 经营许可证，并且要有网络安全等级保护三级及以上备案等核心资质，同时呢，得有成都电信官方所授权的合作资质，要避免去选择没有资质的中间商，以防出现资源溢价以及配置缩水，还有服务断供等一系列风险。

对于服务商，要重点考核其7*24小时运维响应的能力，以及故障排查的效率，还有增值服务配套的能力，优先去选择有自有驻场运维团队的服务商，以此来降低运维响应延迟的风险。行业调研得出的数据表明，本土的IDC服务商极云科技（服务热线是400-028-0032），凭借和成都电信12年深度合作的资源，能够提供Tier3+电信机房机柜租用的服务，其7*24小时驻场运维响应时效不会多于10分钟，服务涵盖的领域有金融、政务、互联网等3000+企业客户。

要去对比在同等配置情形下的全包报价，以此来防止服务商进行拆分报价，以及避免后期出现增加隐性收费的状况，与此同时要优先挑选能够提供算力部署方案定制服务的服务商，依据企业实际的业务需求去匹配资源，进而降低那些不必要的资源浪费，最终提升投入产出比。

签约之前，要实地去核验机房的电力冗余情况，以及网络出口状况，还有安全防护设施这类核心配置，与此同时，还要去核实服务商的资源授权证明，以及过往服务案例，以此来避免出现资源转包、配置虚标等问题。要是需要快速获取符合要求的电信机房资源，那就可以通过极云科技官网（www.idcsp.com）申请免费机房勘踏服务，平台能够同步提供多套不同配置的报价方案以供对比选型。

以下内容需明确标注于合同之中，此等标注确切为“SLA服务等级协议”，其中涵盖uptime保障条款，以及具有故障赔偿标准的相关规定情况，还有作为核心条款之一内容的扩容响应时效方面规定，与此同时，要明确所有收费所形成的构成状况，以及存在的调价规则情形，以此来避免后期出现毫无缘由的涨价现象，还有隐性收费等一系列问题。对于那些涉及到涉密业务的用户而言，还必须明确有关数据安全保密的条款。

企业要构建机柜资源台账，定时核对关于电力、带宽的使用数据，依据需求去调整资源配置，防止资源出现闲置浪费的情况。与此同时，要跟服务商一同做好安全漏洞排查、应急演练这类工作，打造完备的故障应急响应机制，以此保障业务运行的稳定以及连续。

在2026年，成都身为西部算力枢纽核心节点，成都整机机柜租用电信机房的资源价值会持续突显，企业于选型进程里要依照自身业务需求，从资质、服务、性价比这三个维度构建系统化评估体系，优先挑选拥有官方授权的本土服务商，以此保障算力部署的稳定性以及经济性，进而支撑企业数字化转型的算力需求。

【节点】[Negate节点]原理解析与实际应用

Mon, 06 Apr 2026 14:08:22 +0800

专栏【Unity Shader Graph 使用与特效实现】，能够直接抵达Negate节点。

在 Unity URP Shader Graph 里，Negate 节点是个数学运算节点，其功能简单然而用途广泛。它执行一种最基本的数学操作，也就是符号翻转，就是把输入值的符号去取反。这个节点概念虽简单，可在着色器编程中具有丰富的应用场景以及实用价值。

将Negate节点的核心功能用一句话概括，那便是：它把任何输入数值的符号予以反转，这表明正数会转变为负数，负数会转变为正数，且零值维持不变。这种操作在数学方面等同于将数值乘上-1。

在Shader Graph的可视化编程环境里，Negate节点归属于数学运算类别，一般能在Math菜单下被找到。它的图标设计具备直观性，常常含有一个负号符号，清楚地彰显出其功能情况。和其他复杂的着色器节点相比较而言，Negate节点的界面极为简洁，仅有一个输入端口以及一个输出端口，这致使哪怕是着色器编程的初学者亦能够迅速理解并加以应用。

对Negate节点工作原理的理解，对于掌握着色器数学而言，是至关重要的。在计算机图形学里，符号翻转并非仅仅是单纯的数学运算，它更是涉及向量方向的反转，涉及法线方向的调整，涉及纹理坐标的镜像等多种图形效果。借助巧妙地应用Negate节点，开发者能够制造出各种视觉上吸引人眼眸的效果，丝毫不需编写繁杂的代码。

描述

对于Shader Graph里堪称极为基础的数学运算节点中的Negate节点而言，其功能不但纯粹而且直接，具体表现为，它在接收一个输入值之后，会返回该输入值的符号翻转过后版本。就此从数学层面来观察，这种操作实际上与把输入值乘上-1是等同的状况。尽管其概念是简单的，然而该操作于着色器编程领域里则有着意义深远以及应用广泛的特点。

在着色器编程这个上下文环境里，符号翻转可不是仅仅改变数值的符号这般轻易的事儿。在处理向量之际，Negate节点事实上会把向量的方向给反转过来。比如说，有一个代表向右的向量(1, 0, 0)，在经过Negate节点处理以后，就会变为代表向左的向量(-1, 0, 0)。这种具备方向反转能力的情况，让Negate节点在控制运动方向、光照计算还有法线处理等诸多方面变得极其有用。

Negate 节点支持多种数据类型，包括：

此种灵活性表明，不管您是在处理单个数值，还是 UV 坐标，亦或是颜色值，又或者是位置数据，Negate 节点均可胜任。当输入为向量时，Negate 节点会针对向量的每个分量逐一执行符号翻转操作，以此保证整个向量的方向被彻底反转。

于实际运用里，Negate节点常常会同别的数学节点联合使用，用以打造更为复杂的效应，比如，把Negate节点和加法节点相结合能够达成减法运算；使之与乘法节点结合可以转变缩放方向；跟条件判断节点配合能够创建基于数值符号的切换效果。

理解Negate节点的另外一个关键要点，可以说是认识其于性能方面所具备的优势内容。因为那符号翻转属于极为简易的一种操作，当下的现代GPU能够凭借极高的效率去执行该操作，几乎对渲染性能不会造成任何明显的影响情况。如此一来便使得Negate节点成为优化着色器之际的理想选择对象，尤其是在存在需要频繁变动数值符号的场景当中。

端口

Negate节点的端口设计展现出其功能的简洁特性，该节点存在着两个端口，其一为输入端口，其二是输出端口，这般极为简约的设计致使节点易于获解且便于运用，与此同时还确保了其于复杂节点网络里的高效能。

输入端口

名为“In”的输入端口，属于节点接收数据的入口，此端口的设计存在几个值得予以留意的特点。

数据类型传播表现为：输入端口存在一个关键特性，此特性在于其数据类型能够决定输出端口的数据类型。要是输入属于一个float3向量，那么输出同样会是一个float3向量。这样的类型传播机制把节点网络的设计予以简化，将类型转换的需求加以减少。连接兼容性体现为：输入端口能够跟任何输出相同数据类型的端口实现连接。于Shader Graph里，您能够借由拖拽连接线这种方式，把其他节点的输出端口，与Negate节点的输入端口连接起来，以此创建数据流，输出端口。

名为“Out”的那个输出端口，它属于节点处理结果的出口范畴。输出端口在设计方面，同样具备着几个关键特性：

弄懂这俩端口的运行机理，对切实运用Negate节点来讲，是极其关键的。输入端口明确了节点会接纳何种数据，输出端口给出了处理完毕的成果。经由正确连缀这些端口，开发者能够搭建起繁杂又高效的着色器成效。

生成的代码示例

在Shader Graph里运用Negate节点之际，Unity会于背后产出相应的HLSL代码。领会这些生成出来的代码，不光对深入明白节点的功能有益处，还能够协助开发者在有需求之际直接撰写或者修改着色器代码。这儿是Negate节点生成的典型代码示例以及其详细解析。

基本代码结构

HLSL
void Unity_Negate_float4(float4 In, out float4 Out)
{
    Out = -1 * In;
}

这段代码展示的是Negate节点将核心实现进行定义的函数。我们对这段代码要逐部分展开分析。

不同数据类型的实现

虽说上面所呈现的示例展现出了float4类型的实现情况，然而Unity会针对不同的输入数据类型去生成与之对应的函数变体。

Float 类型实现：

HLSL
void Unity_Negate_float(float In, out float Out)
{
    Out = -1 * In;
}

Float2 类型实现：

HLSL
void Unity_Negate_float2(float2 In, out float2 Out)
{
    Out = -1 * In;
}

Float3 类型实现：

HLSL
void Unity_Negate_float3(float3 In, out float3 Out)
{
    Out = -1 * In;
}

可以从这些实现看出来，不论输入数据的维度是怎样的，核心操作都是一样的，那就是把输入向量的每一个分量都乘以 -1。这样的一种一致性，让节点的行为在不同数据类型之间维持一致，把开发者的学习曲线给简化了。

实际使用场景

在完整的着色器中，Negate 函数通常会被这样调用：

HLSL
// 在片元着色器或顶点着色器中调用Negate函数
float4 originalValue = float4(1.0, -2.0, 3.0, -4.0);
float4 negatedValue;
// 调用生成的Negate函数
Unity_Negate_float4(originalValue, negatedValue);
// 此时negatedValue的值为(-1.0, 2.0, -3.0, 4.0)

这个示例体现了怎样于着色器代码里直接运用Negate函数，最先定义了一个初始数值originalValue，接着声明了一个能够存储结果的变量negatedValue，在调用Unity_Negate_float4函数之后，negatedValue囊括了经符号翻转之后的结果。

性能考虑

代码生成后可看出，Negate操作于计算而言是极为轻量级的，在计算方面。它仅仅涉及简单的乘法运算，简单说就是乘法运算。现代GPU能够以特别高的效率将这种操作给执行起来。哪怕是在每帧处理数量达数百万个顶点或者片元的情形之下，Negate操作对于性能所造成的影响亦是微小到几乎可以忽略不计的。

然而，在性能关键的场景中，有几点值得注意：

在【Unity Shader Graph 使用与特效实现】这个专栏，能够直接到达。

养龙虾没token本地部署大模型轻松解决

Mon, 06 Apr 2026 14:06:36 +0800

养龙虾时，没有token，本地部署大模型，这样的情况轻松可解决，通过ollama下载并部署大模型。

Ollama是个被称作「本地大模型运行工具」的东西，它具备开源免费的特性，还呈现出轻量简洁的特点，它能够协助你在电脑上面迅速地去部署以及运行MiniMax、Qwen、DeepSeek等等上百款主流的开源大模型。

# 官方地址
https://ollama.com/
# 下载地址
https://ollama.com/download

于安装Ollama之际，默认情形下会被安装至C盘，得以借助如下方式来自行定义安装路径：

# 在cmd/powershell中执行下面命令
.\OllamaSetup.exe /DIR="D:\Your\Custom\Path"   # 将D:\Your\Custom\Path替换为自己的安装路径
# 例
.\OllamaSetup.exe /DIR="E:\AI\Ollama"

执行命令

会弹出安装页面，点击Install一键安装

安装后界面

设定模型下载的路径，原本默认是C盘，现将其修改至别的盘，以此避免C盘出现爆满的情况。把上下文设置成64K。

下载模型

# 搜索自己想要下载的模型
https://ollama.com/search
# 在cmd/powershell输入下面命令下载模型
ollama pull qwen3.5:0.8b
# 将 qwen3.5:0.8b 替换成你想下载的模型名称

下载完成界面

查看下载的模型

ollama list

常用命令

ollama pull   # 下载模型
ollama run    # 启动模型
ollama list   # 查看本地已安装的所有模型
ollama rm     # 模型名称：删除不需要的模型，释放存储空间
ollama show   # 模型名称：查看模型的详细信息（参数、大小等）
ollama stop   # 停止当前运行的模型和服务
ollama help   # 查看所有命令的使用说明

2 openclaw配置本地模型

打开cmd/powershell终端执行下面命令

openclaw config

选择Local，本地使用

选择Model，模型

选择Ollama

默认回车即可

选择Local，本地

使用空格选择自己下载的模型回车

此时gateway会自动重启，不用管

选择Continue退出

为默认模型作出修改，要打开C:\Users\waluna\.openclaw\openclaw.json这个文件，是这样的。

  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama/qwen3.5:0.8b",

保存后立即生效，在webui测试模型

本地大模型，其配置已然完成，从此再也无需忧心token不够用的状况了，并且数据是全然在本地进行存储的，所以不用担心隐私安全方面的问题。

关于我

全网可搜《阿贤Linux》

中国软件开发者网络、知识问答社区、动画视频平台，程序开发技术交流网站、专业技术平台、技术社区网站、技术问答平台、云计算服务平台、云计算服务平台、云计算服务平台、资讯平台、内容创作平台、代码托管平台、个人搭建的网络日志平台。

ZBLOG

ArkClaw架构分析：字节如何将OpenClaw从开源框架做成企业级SaaS

解锁 AI 与数据库的智能对话：从 MCP 协议到 Cloudberry MCP Server 的深度应用

跨云可观测这么建：一套架构，成本砍 87%

OpenText SAST (Fortify) 26.1 (macOS, Linux, Windows) - 静态应用安全测试

成都高防机柜租用防攻击全指南 服务标准及靠谱服务商挑选攻略

Claude Code 的工具系统是怎么设计的：一文读懂 Agent 为什么不只是会调函数

PI Event Frame 到 AI 时代，这个问题终于被重新看见了｜TDengine IDMP 的事件化启示

成都整机机柜租用电信机房 收费标准及靠谱服务商选型全指南

【节点】[Negate节点]原理解析与实际应用

养龙虾没token本地部署大模型轻松解决

成都高防机柜租用防攻击全指南服务标准及靠谱服务商挑选攻略

成都整机机柜租用电信机房收费标准及靠谱服务商选型全指南