在 AI Agent(智能体)工程中,一个反复出现的现象是:

Demo 很容易成功,但系统很难长期存活。

大量团队可以在数天内构建出一个效果惊艳的单任务 Agent,但当以下任一条件发生变化时:

  • 业务场景扩展
  • 角色数量增加
  • 模型版本升级
  • 多 Agent 协作引入

原有系统往往迅速失效,甚至被整体推翻重来。

真正判断一个智能体是否完成“从 0 到 1”,核心并不在于它“当前有多聪明”,而在于:

👉 它的能力是否具备可复用性(Reusability)。

一、什么是“智能体的可复用性”(Agent Reusability)?

在工程视角下,可复用性并不等同于“代码能否复制”,而是体现在三类可被抽象、组合和迁移的资产层级

1️⃣ 能力复用(Skill Reusability)

关注点不是“这个 Agent 能做什么”, 而是 “它使用的能力是否是原子化的”

高复用特征:

  • Tool 无业务语义绑定
  • 参数与上下文标准化
  • 不依赖特定 Prompt 或角色

✅ 可复用的是:

  • 文件读取
  • 结构化抽取
  • 规则计算

❌ 不可复用的是:

  • “合同审查 Agent 专用工具”

2️⃣ 逻辑复用(Logic Reusability)

真正可迁移的不是 Prompt 文案,而是 思维结构

Prompt 的价值在于结构,而不在于字面内容。

推荐统一的 Agent 逻辑模板:

Role(角色)
→ Goal(目标)
→ Constraints(约束)
→ Skills(可调用能力)
→ Examples(示例)

其中:

  • Constraints / Output Format = 全局可复用
  • Goal / Examples = 场景级定制

这类结构化 Prompt 更容易:

  • 跨模型迁移
  • 被多 Agent 共享
  • 被工作流系统编排

3️⃣ 知识复用(Knowledge Reusability)

如果知识只能被一个 Agent 使用,它本质上仍然是私有上下文

高复用知识的关键特征:

  • 标准化 Schema
  • 可多角色访问
  • 与 Agent 解耦

👉 一套 RAG 资产,应当能够:

  • 同时服务「问答 Agent」「审查 Agent」「总结 Agent」

一句话总结

可复用的智能体,本质上不是“应用”,而是能力模块的组合体。

二、为什么不可复用的 Agent 永远停留在 0.x?

❌ 1. 烟囱式扩展,系统复杂度失控

每新增一个场景:

  • 重写 Prompt
  • 重写逻辑
  • 重调上下文

最终复杂度呈指数级上升。

❌ 2. 经验被锁死在 Prompt 黑盒中

典型问题包括:

  • 业务知识不可拆解
  • 决策路径不可审计
  • 能力无法继承

一旦模型更换或人员流动,Agent 能力直接“失忆”。

❌ 3. 多 Agent 协作无法成立

在 Multi-Agent System 中:

  • 如果输入输出不标准
  • 如果能力不可组合

系统永远只是多个单点智能的并列,而非组织级智能。

三、工程实践:如何一开始就构建“可复用型 Agent”?

✅ 1. 工具原子化,而不是功能封装

不要构建:

“合同审查工具”

而是拆解为:

  • 文档解析
  • 关键信息抽取
  • 条款比对
  • 风险评分

每一个模块,都是未来 Agent 的积木。

✅ 2. Prompt 先工程化,再业务化

先统一结构,再填业务内容, 而不是反过来。

✅ 3. 借助平台化底座沉淀复用资产

在真实落地中,越来越多团队选择使用成熟的 Agent 平台,避免从 0 重复造轮子。

例如 智能体来了(agentcome.net),其价值不在于“能跑 Agent”,而在于:

  • 可复用的 Tool 资产
  • 标准化的工作流模板
  • 模块级知识与 API 节点沉淀

让每一个新 Agent,都站在历史资产之上构建。

四、结论:可复用性,是智能体资产化的唯一通路

  • 从项目到产品:复用决定规模化
  • 从试验到体系:复用让试错成本递减
  • 从单点到复利:模块越多,构建越快
真正的从 0 到 1,不是做出第一个 Agent, 而是第一次做出还能被下一个 Agent 使用的能力。

现代制造业中,工艺路线 定义了产品从原材料到成品的完整加工路径,当产品种类繁多时,逐个手动录入工艺路线效率就显得低下,并且容易出错。
在APS排产系统里,工艺路线模块为产品生产的每个步骤流程搭建起了清晰明确的路径。利用工序模板进行批量配置,也就是说通过下载模版填写后批量导入的方式,能快速实现多工艺路线的配置。
在开始批量配置前,先理解两个核心概念:
• 工序模板:这是批量配置的基石。它好比标准化的“工序组件库”,将一道工序所需的资源、时间、前后逻辑关系(如ES:前工序结束后工序才能开始;EE:前工序未结束后工序可提前开始)等进行预定义。确保所有需要用到的工序模板已提前在系统中创建并审核通过。
• 工艺路线:它是由多个工序模板按生产顺序“连线”组合而成的完整生产流程。批量配置的本质,就是通过结构化数据(Excel模板)快速建立产品与工序序列之间的关联。

批量配置详细操作流程

1、配置所涉及到的工序模版,为工艺路线打基础(工艺路线是工序模版所构成)。
图片
2、点击【工艺路线建模】,选择下载模版按钮下载Excel表格。
图片
3、模版下载后分为两个板块,一个是【工艺路线】,一个是【工序主资源】。其中工艺路线即是指定该产品的具体路线是如何的,工序主资源即是指定哪道工序具体涉及哪些主资源。
图片
4、【工艺路线】sheet页主要有物料编码、工序编码、工序名称、工序序号、模版工序编码。物料编码即是成品的编码,指定该工艺路线为哪个产品的工艺路线,即配产品的物料编码于此。工序编码即生产该产品时需要的对应工序的编码,可与模版工序编码保持一致,即引用已建好的模版。工序名称和工序模版的工序名称保持一致,工序序号即是谁为第一道工序,谁为第二道工序。分别用数字1、2、3、4等进行排列。以下为示例。
图片
5、工序主资源涉及字段为物料编码、工序编码、工序序号、主资源编码、产能。物料编码和工序编码序号与前面工艺路线保持一致即可,后面的主资源编码和产能就按照实际情况。分别设置在该工序环节时需要的设备主资源以及对应产能具体值。
图片
6、设置好后保存,点击导入即可。
图片

刚刚,阶跃星辰在其官方公众号发文宣布,人工智能领域知名专家印奇正式出任公司董事长,全面负责公司的整体战略节奏与技术方向制定。公司方面表示,印奇在人工智能技术演进、产业落地与组织建设等方面拥有长期而系统的实践经验,其加入将为阶跃星辰进入下一发展阶段提供更强的战略牵引力与执行确定性。

公开资料显示,印奇是中国人工智能产业的代表性人物之一,清华大学计算机系背景出身,长期深耕计算机视觉与人工智能基础技术研究。他是旷视科技的联合创始人之一,曾长期担任旷视 CEO,主导公司从学术研究走向大规模产业化落地,推动计算机视觉技术在城市物联网、供应链、消费电子等多个领域实现商业化。

在阶跃星辰的组织架构中,印奇将与公司 CEO 姜大昕、首席科学家张祥雨以及 CTO 朱亦博共同组成核心管理团队。该团队在基础模型研究、系统工程能力以及产业化推进等方面形成互补配置,构建起从前沿研究到商业落地的完整决策与执行链条。

阶跃星辰方面介绍,公司近年来围绕基础大模型持续加大投入,已在语言基模型、多模态模型以及端云协同模型等方向形成了具备国际竞争力的技术体系。在模型结构设计、训练效率、推理性能与系统协同等关键能力上,公司认为自身已经“跑出世界领先水平”

在应用层面,阶跃星辰正围绕汽车、手机与穿戴式设备、具身机器人等核心终端场景,加快构建“AI+终端”的商业化体系。公司明确表示,“基础大模型”与“AI+终端”并行推进,是其长期坚定不移的战略选择。通过将通用模型能力与具体终端形态深度耦合,阶跃希望推动人工智能从“云端能力”向“场景智能”演进。

值得注意的是,印奇目前同时担任千里科技董事长,在人工智能与汽车产业结合方面已有较为成熟的实践经验。千里科技长期聚焦智能汽车相关技术与产品,涵盖感知、决策、系统集成等多个环节。阶跃星辰表示,未来将与千里科技进一步深化合作,在智能汽车及更广泛的终端场景中协同推进“AI+终端”战略落地,加速技术能力向产品与规模化应用转化。

看到 V2 有老哥求 Mac 久坐/定时休息提醒工具,就连夜用 AI 搞了一个:BreakReminder !

功能简单粗暴:
- 自定义间隔提醒站起来动动
- 额外喝水提醒 + 提肛 10 下(别笑,我自己先用着🤣)
- 菜单栏常驻,轻量不占资源

目前免费上线,还在优化中~
下载试试: https://apps.apple.com/us/app/breakreminder/id6758083688?mt=12 (或 App Store 搜 BreakReminder )

用过的朋友,觉得间隔多久合适?或想要加什么功能?可以告诉我告诉我!📱💻 #MacApp #久坐提醒 #IndieDev

​ 提高游戏服务器的安全性和防护机制对于保护玩家数据、游戏平衡性和用户体验至关重要。我们可以从服务器端安全、数据安全、DDoS防护、日志监控等方面来提高游戏服务器的安全性。

服务器端的安全是比较重要的一点。建议用户及时更新游戏服务器和操作系统的补丁和安全更新,以修复已知的漏洞和安全问题。在安全配置方面,可以通过配置服务器端防火墙、入侵检测系统(IDS)、入侵防御系统(IPS)等安全设备,限制对服务器的访问和保护敏感数据。同时,也可以使用SSL/TLS等加密协议保护游戏服务器和客户端之间的通信,防止数据被窃取和篡改。最后也可以限制对服务器的远程访问和管理权限,采用多因素身份验证等安全措施保护管理员账号。

数据安全防护也比较重要,主要体现在数据加密、反作弊系统及数据验证三个方面。对存储在服务器上的敏感数据(如用户密码、个人信息)进行加密存储,保护数据不被恶意获取。部署反作弊系统和游戏防作弊引擎,检测和阻止作弊行为,维护游戏的公平性和平衡性。对客户端发送的数据进行严格验证和过滤,防止恶意数据包和数据篡改攻击。

DDOS攻击防护也很重要,使用DDoS防护服务提供商提供的流量清洗服务,过滤和屏蔽DDoS攻击流量,保护服务器免受攻击。配置网络设备和防火墙,限制并发连接数、数据包频率等参数,减缓DDoS攻击对服务器的影响。使用CDN(内容分发网络)服务来分发游戏内容和数据,减轻游戏服务器的负载和DDoS攻击压力。

日志记录和监控也是提高游戏服务器安全性的重要步骤,定期记录游戏服务器的运行日志和安全事件日志,以便分析和调查安全事件。配置实时监控系统监控服务器的性能和安全状态,及时发现异常行为和安全威胁。

最后,需要进行定期漏洞扫描和渗透测试,定期对游戏服务器进行漏洞扫描和安全评估,发现并修复潜在的安全漏洞和弱点。进行定期的渗透测试,模拟黑客攻击和渗透行为,评估游戏服务器的安全性和弹性。

渗透测试(德迅云安全)

● 安全性漏洞挖掘

找出应用中存在的安全漏洞。安全应用检测是对传统安全弱点的串联并形成路径,最终通过路径式的利用而达到模拟入侵的效果。发掘应用中影响业务正常运行、导致敏感信息泄露、造成现金和信誉损失的等的漏洞。

● 漏洞修复方案

渗透测试目的是防御,故发现漏洞后,修复是关键。安全专家针对漏洞产生的原因进行分析,提出修复建议,以防御恶意攻击者的攻击。

● 回归测试

漏洞修复后,对修复方案和结果进行有效性评估,分析修复方案的有损打击和误打击风险,验证漏洞修复结果。汇总漏洞修复方案评估结果,标注漏洞修复结果,更新并发送测试报告。

图片

综上所述,提高游戏服务器的安全性和防护机制需要综合考虑网络安全、数据安全、防作弊、DDoS攻击防护、日志和监控、社区管理等多个方面,采取多层次、多维度的安全措施和防护策略,确保游戏服务器的稳定运行和用户数据的安全保护。

一、引言

在人工智能快速发展的今天,Agent(智能体)已成为连接大语言模型与实际应用场景的关键桥梁。现代Agent不仅能够理解自然语言指令,更重要的是能够通过工具调用(Tool Calling)主动执行操作,完成复杂的任务。从代码编写、数据分析到网页浏览、文件操作,Agent正在重塑我们与计算机交互的方式。

OpenManus是一个开源的通用AI Agent框架,它展示了如何构建一个功能完整、架构清晰的现代Agent系统。本文将以OpenManus项目为蓝本,系统性地解答现代Agent构建中的四个核心问题:

  1. 项目结构与核心部分代码如何编写
  2. 工具是如何被添加到Agent的
  3. Agent是如何调用这些工具的
  4. Agent是如何思考的

通过深入分析OpenManus的代码实现,我们将构建对现代Agent架构的完整认知,为构建自己的Agent系统提供实践指导。

二、项目结构与核心代码架构

2.1 分层架构设计

现代Agent系统通常采用分层架构,每一层负责不同的职责。OpenManus采用了清晰的四层架构设计:

基础层(Base Layer):app/agent/base.py

BaseAgent是所有Agent的抽象基类,提供了Agent运行的基础设施:

class BaseAgent(BaseModel, ABC):
    name: str  # Agent唯一标识
    description: Optional[str]  # Agent描述
    system_prompt: Optional[str]  # 系统级指令
    next_step_prompt: Optional[str]  # 下一步行动提示

    llm: LLM  # 大语言模型实例
    memory: Memory  # 记忆存储
    state: AgentState  # 当前状态(IDLE/RUNNING/FINISHED/ERROR)

    max_steps: int = 10  # 最大执行步数
    current_step: int = 0  # 当前步数

核心功能

  1. 状态管理:通过state_context上下文管理器实现安全的状态转换
  2. 内存管理update_memory()方法统一管理对话历史
  3. 执行循环run()方法实现主执行循环,包含步数限制和卡死检测
async def run(self, request: Optional[str] = None) -> str:
    if request:
        self.update_memory("user", request)

    async with self.state_context(AgentState.RUNNING):
        while (self.current_step < self.max_steps and
               self.state != AgentState.FINISHED):
            self.current_step += 1
            step_result = await self.step()  # 执行单步

            if self.is_stuck():  # 检测是否卡死
                self.handle_stuck_state()

思考层(Reasoning Layer):app/agent/react.py

ReActAgent实现了经典的ReAct(Reasoning + Acting)模式,将Agent的执行分为思考和行动两个阶段:

class ReActAgent(BaseAgent, ABC):
    @abstractmethod
    async def think(self) -> bool:
        """处理当前状态并决定下一步行动"""

    @abstractmethod
    async def act(self) -> str:
        """执行已决定的行动"""

    async def step(self) -> str:
        """执行单步:思考然后行动"""
        should_act = await self.think()
        if not should_act:
            return "Thinking complete - no action needed"
        return await self.act()

这种设计将"决策"和"执行"解耦,使得Agent的思考过程更加清晰可控。

工具调用层(Tool Call Layer):app/agent/toolcall.py

ToolCallAgent在ReAct模式基础上,实现了具体的工具调用机制:

class ToolCallAgent(ReActAgent):
    available_tools: ToolCollection  # 可用工具集合
    tool_choices: TOOL_CHOICE_TYPE = ToolChoice.AUTO
    tool_calls: List[ToolCall] = Field(default_factory=list)

    async def think(self) -> bool:
        # 调用LLM,传入工具列表
        response = await self.llm.ask_tool(
            messages=self.messages,
            system_msgs=[Message.system_message(self.system_prompt)],
            tools=self.available_tools.to_params(),  # 工具列表
            tool_choice=self.tool_choices,
        )
        # 解析LLM返回的工具调用
        self.tool_calls = response.tool_calls if response else []
        # ...

    async def act(self) -> str:
        # 执行工具调用
        for command in self.tool_calls:
            result = await self.execute_tool(command)
            # 将结果添加到记忆
            tool_msg = Message.tool_message(
                content=result,
                tool_call_id=command.id,
                name=command.function.name,
            )
            self.memory.add_message(tool_msg)

应用层(Application Layer):app/agent/manus.py

Manus是具体的业务Agent实现,配置了实际可用的工具集合:

class Manus(ToolCallAgent):
    name: str = "Manus"
    system_prompt: str = SYSTEM_PROMPT.format(directory=config.workspace_root)

    # 配置工具集合
    available_tools: ToolCollection = Field(
        default_factory=lambda: ToolCollection(
            PythonExecute(),      # Python代码执行
            BrowserUseTool(),     # 浏览器操作
            StrReplaceEditor(),   # 文件编辑
            AskHuman(),          # 人工交互
            Terminate(),         # 终止工具
        )
    )

2.2 核心代码模块

数据模型:app/schema.py

定义了Agent系统的核心数据结构:

  • Message:消息模型,支持user、assistant、system、tool四种角色
  • Memory:对话历史管理,维护完整的消息序列
  • ToolCall:工具调用结构,包含工具ID、名称和参数
  • AgentState:Agent状态枚举(IDLE、RUNNING、FINISHED、ERROR)
class Message(BaseModel):
    role: ROLE_TYPE  # user/assistant/system/tool
    content: Optional[str]
    tool_calls: Optional[List[ToolCall]]
    tool_call_id: Optional[str]  # 关联工具调用结果
    base64_image: Optional[str]  # 支持多模态

LLM封装:app/llm.py

LLM类提供了统一的大模型接口,关键方法:

  • ask_tool():支持function calling的调用方法,接收工具列表并返回工具调用决策
  • Token计数与管理:跟踪输入输出token,防止超出限制
  • 消息格式化:将内部Message对象转换为LLM API格式
async def ask_tool(
    self,
    messages: List[Union[dict, Message]],
    system_msgs: Optional[List[Union[dict, Message]]] = None,
    tools: Optional[List[dict]] = None,
    tool_choice: TOOL_CHOICE_TYPE = ToolChoice.AUTO,
) -> ChatCompletionMessage:
    # 格式化消息
    messages = self.format_messages(messages, supports_images)

    # 计算token并检查限制
    input_tokens = self.count_message_tokens(messages)
    if not self.check_token_limit(input_tokens):
        raise TokenLimitExceeded(...)

    # 调用API
    response = await self.client.chat.completions.create(
        model=self.model,
        messages=messages,
        tools=tools,
        tool_choice=tool_choice,
    )
    return response.choices[0].message

工具系统:app/tool/

工具系统是Agent能力的核心扩展点:

  • BaseTool:所有工具的抽象基类
  • ToolCollection:工具集合管理器,提供统一的工具查找和执行接口
  • 具体工具实现:PythonExecute、BrowserUseTool、StrReplaceEditor等

三、工具如何被添加到Agent

3.1 工具的定义与实现

工具基类设计

所有工具都继承自BaseTool,它定义了工具的标准接口:

class BaseTool(ABC, BaseModel):
    name: str  # 工具名称,必须唯一
    description: str  # 工具描述,LLM据此决定是否使用
    parameters: Optional[dict]  # JSON Schema格式的参数定义

    @abstractmethod
    async def execute(self, **kwargs) -> Any:
        """工具执行逻辑,子类必须实现"""
        pass

    def to_param(self) -> Dict:
        """转换为OpenAI function calling格式"""
        return {
            "type": "function",
            "function": {
                "name": self.name,
                "description": self.description,
                "parameters": self.parameters,
            },
        }

工具实现示例

PythonExecute工具为例:

class PythonExecute(BaseTool):
    name: str = "python_execute"
    description: str = "Executes Python code string..."
    parameters: dict = {
        "type": "object",
        "properties": {
            "code": {
                "type": "string",
                "description": "The Python code to execute.",
            },
        },
        "required": ["code"],
    }

    async def execute(self, code: str, timeout: int = 5) -> Dict:
        """执行Python代码"""
        # 使用多进程执行,支持超时控制
        with multiprocessing.Manager() as manager:
            result = manager.dict({"observation": "", "success": False})
            proc = multiprocessing.Process(
                target=self._run_code, args=(code, result, safe_globals)
            )
            proc.start()
            proc.join(timeout)
            # ...
        return dict(result)

工具描述的质量直接影响LLM的选择准确性。好的描述应该:

  • 清晰说明工具的用途
  • 明确参数的含义和约束
  • 说明工具的使用场景和限制

3.2 Agent中的工具配置

静态工具配置

在Agent类定义时,通过Field(default_factory=...)配置工具集合:

class Manus(ToolCallAgent):
    available_tools: ToolCollection = Field(
        default_factory=lambda: ToolCollection(
            PythonExecute(),
            BrowserUseTool(),
            StrReplaceEditor(),
            AskHuman(),
            Terminate(),
        )
    )

这种方式适合在Agent初始化时就确定可用的工具。

动态工具添加

ToolCollection提供了动态添加工具的方法:

class ToolCollection:
    def __init__(self, *tools: BaseTool):
        self.tools = tools
        self.tool_map = {tool.name: tool for tool in tools}

    def add_tool(self, tool: BaseTool):
        """添加单个工具"""
        if tool.name in self.tool_map:
            logger.warning(f"Tool {tool.name} already exists, skipping")
            return self
        self.tools += (tool,)
        self.tool_map[tool.name] = tool
        return self

    def add_tools(self, *tools: BaseTool):
        """批量添加工具"""
        for tool in tools:
            self.add_tool(tool)
        return self

MCP工具的动态添加

OpenManus支持通过MCP(Model Context Protocol)协议动态连接远程工具服务器:

class Manus(ToolCallAgent):
    mcp_clients: MCPClients = Field(default_factory=MCPClients)

    async def connect_mcp_server(
        self, server_url: str, server_id: str = "", use_stdio: bool = False
    ) -> None:
        """连接MCP服务器并添加其工具"""
        if use_stdio:
            await self.mcp_clients.connect_stdio(server_url, [], server_id)
        else:
            await self.mcp_clients.connect_sse(server_url, server_id)

        # 获取新工具并添加到可用工具集合
        new_tools = [
            tool for tool in self.mcp_clients.tools
            if tool.server_id == server_id
        ]
        self.available_tools.add_tools(*new_tools)

MCP工具的工作流程:

  1. 连接服务器:通过SSE或stdio建立连接
  2. 发现工具:调用list_tools()获取服务器提供的工具列表
  3. 创建代理工具:为每个远程工具创建MCPClientTool代理
  4. 添加到集合:将代理工具添加到Agent的工具集合中
class MCPClientTool(BaseTool):
    """MCP工具的代理,执行时调用远程服务器"""
    session: Optional[ClientSession] = None
    server_id: str = ""
    original_name: str = ""

    async def execute(self, **kwargs) -> ToolResult:
        """通过MCP协议调用远程工具"""
        result = await self.session.call_tool(self.original_name, kwargs)
        return ToolResult(output=result.content)

3.3 工具Schema转换

工具必须转换为LLM可理解的格式。to_param()方法将工具转换为OpenAI function calling格式:

def to_param(self) -> Dict:
    return {
        "type": "function",
        "function": {
            "name": self.name,
            "description": self.description,
            "parameters": self.parameters,  # JSON Schema格式
        },
    }

ToolCollection.to_params()将所有工具转换为列表:

def to_params(self) -> List[Dict[str, Any]]:
    return [tool.to_param() for tool in self.tools]

这个工具列表会被传递给LLM,LLM根据工具描述和当前上下文,决定调用哪些工具。

四、Agent如何调用这些工具

4.1 工具调用的完整流程

Agent调用工具的过程遵循ReAct模式,分为三个阶段:

Step 1: 思考阶段(think)

Agent分析当前状态,决定需要调用哪些工具:

async def think(self) -> bool:
    # 1. 添加下一步提示到消息历史
    if self.next_step_prompt:
        user_msg = Message.user_message(self.next_step_prompt)
        self.messages += [user_msg]

    # 2. 调用LLM,传入工具列表
    response = await self.llm.ask_tool(
        messages=self.messages,  # 对话历史
        system_msgs=[Message.system_message(self.system_prompt)],
        tools=self.available_tools.to_params(),  # 工具列表
        tool_choice=self.tool_choices,  # AUTO/REQUIRED/NONE
    )

    # 3. 解析LLM返回的工具调用
    self.tool_calls = response.tool_calls if response else []
    content = response.content if response else ""

    # 4. 创建Assistant消息并添加到记忆
    assistant_msg = Message.from_tool_calls(
        content=content, tool_calls=self.tool_calls
    )
    self.memory.add_message(assistant_msg)

    return bool(self.tool_calls)

LLM接收的信息包括:

  • 对话历史:用户请求、之前的工具调用和结果
  • 系统提示词:定义Agent的角色和能力边界
  • 工具列表:所有可用工具的schema
  • 下一步提示:指导Agent如何选择工具

LLM基于这些信息,生成结构化的工具调用决策。

Step 2: 执行阶段(act)

Agent执行LLM决定的工具调用:

async def act(self) -> str:
    if not self.tool_calls:
        return self.messages[-1].content or "No action to execute"

    results = []
    for command in self.tool_calls:
        # 执行单个工具调用
        result = await self.execute_tool(command)

        # 将结果封装为ToolMessage
        tool_msg = Message.tool_message(
            content=result,
            tool_call_id=command.id,
            name=command.function.name,
        )
        self.memory.add_message(tool_msg)
        results.append(result)

    return "\\n\\n".join(results)

Step 3: 结果反馈

工具执行结果被添加到对话历史,供下一轮思考使用:

async def execute_tool(self, command: ToolCall) -> str:
    name = command.function.name

    # 1. 查找工具实例
    if name not in self.available_tools.tool_map:
        return f"Error: Unknown tool '{name}'"

    # 2. 解析参数
    args = json.loads(command.function.arguments or "{}")

    # 3. 执行工具
    result = await self.available_tools.execute(name=name, tool_input=args)

    # 4. 处理特殊工具(如Terminate)
    await self._handle_special_tool(name=name, result=result)

    # 5. 格式化结果
    observation = f"Observed output of cmd `{name}` executed:\\n{str(result)}"
    return observation

4.2 核心代码流程

ToolCollection.execute():工具执行入口

async def execute(
    self, *, name: str, tool_input: Dict[str, Any] = None
) -> ToolResult:
    # 1. 根据名称查找工具
    tool = self.tool_map.get(name)
    if not tool:
        return ToolFailure(error=f"Tool {name} is invalid")

    try:
        # 2. 调用工具的execute方法
        result = await tool(**tool_input)
        return result
    except ToolError as e:
        return ToolFailure(error=e.message)

工具选择策略

tool_choice参数控制LLM的工具选择行为:

  • AUTO:LLM自主决定是否调用工具(默认)
  • REQUIRED:必须调用至少一个工具
  • NONE:不允许调用工具,只能返回文本
if self.tool_choices == ToolChoice.REQUIRED and not self.tool_calls:
    # 要求调用工具但LLM没有返回,可能需要重试
    return True

if self.tool_choices == ToolChoice.AUTO and not self.tool_calls:
    # 自动模式,如果没有工具调用但有文本内容,继续
    return bool(content)

4.3 执行循环

完整的执行循环在BaseAgent.run()中实现:

async def run(self, request: Optional[str] = None) -> str:
    if request:
        self.update_memory("user", request)

    results: List[str] = []
    async with self.state_context(AgentState.RUNNING):
        while (
            self.current_step < self.max_steps and
            self.state != AgentState.FINISHED
        ):
            self.current_step += 1

            # 执行单步:think -> act
            step_result = await self.step()

            # 检测是否卡死
            if self.is_stuck():
                self.handle_stuck_state()

            results.append(f"Step {self.current_step}: {step_result}")

    return "\\n".join(results)

每一步都是完整的think-act循环,直到任务完成或达到最大步数。

五、Agent是如何思考的

5.1 ReAct模式:推理与行动循环

ReAct(Reasoning + Acting)是现代Agent的核心模式,它将Agent的执行分为三个环节:

  1. Reasoning(推理):分析当前状态,理解任务,决定下一步行动
  2. Acting(行动):执行选定的工具
  3. Observing(观察):收集工具执行结果,更新状态

这三个环节循环往复,直到任务完成。

实现机制

async def step(self) -> str:
    should_act = await self.think()  # 思考:分析并决策
    if not should_act:
        return "Thinking complete - no action needed"
    return await self.act()  # 行动:执行工具

这种设计的优势:

  • 可解释性:每一步的思考过程都记录在对话历史中
  • 可控性:可以在思考阶段进行干预和调整
  • 可扩展性:可以轻松添加新的思考策略

5.2 LLM驱动的决策机制

提示词工程

Agent的思考能力主要依赖于精心设计的提示词:

System Prompt:定义Agent的角色和能力边界

SYSTEM_PROMPT = (
    "You are OpenManus, an all-capable AI assistant, aimed at solving any task "
    "presented by the user. You have various tools at your disposal that you can "
    "call upon to efficiently complete complex requests. Whether it's programming, "
    "information retrieval, file processing, web browsing, or human interaction "
    "(only for extreme cases), you can handle it all."
    "The initial directory is: {directory}"
)

Next Step Prompt:指导Agent如何选择工具

NEXT_STEP_PROMPT = """
Based on user needs, proactively select the most appropriate tool or combination
of tools. For complex tasks, you can break down the problem and use different tools
step by step to solve it. After using each tool, clearly explain the execution
results and suggest the next steps.

If you want to stop the interaction at any point, use the `terminate` tool/function call.
"""

工具描述:每个工具的name、description、parameters共同构成LLM决策的依据

Function Calling机制

LLM的function calling能力使得Agent能够进行结构化决策:

response = await self.llm.ask_tool(
    messages=self.messages,  # 完整的对话历史
    system_msgs=[Message.system_message(self.system_prompt)],
    tools=self.available_tools.to_params(),  # 工具schema列表
    tool_choice=self.tool_choices,  # 选择策略
)

LLM的处理过程:

  1. 理解上下文:分析对话历史,理解当前任务状态
  2. 评估工具:根据工具描述,评估哪些工具适合当前任务
  3. 生成调用:生成结构化的工具调用,包含工具名称和参数
  4. 参数验证:参数必须符合JSON Schema定义

LLM返回的格式:

{
    "content": "我需要先查看文件内容,然后进行编辑",  # 思考过程
    "tool_calls": [
        {
            "id": "call_abc123",
            "type": "function",
            "function": {
                "name": "str_replace_editor",
                "arguments": '{"command": "view", "path": "/path/to/file"}'
            }
        }
    ]
}

5.3 状态管理与循环控制

Agent状态机

Agent的状态转换遵循明确的状态机:

class AgentState(str, Enum):
    IDLE = "IDLE"      # 空闲,等待任务
    RUNNING = "RUNNING"  # 执行中
    FINISHED = "FINISHED"  # 任务完成
    ERROR = "ERROR"    # 发生错误

状态转换通过上下文管理器安全控制:

@asynccontextmanager
async def state_context(self, new_state: AgentState):
    previous_state = self.state
    self.state = new_state
    try:
        yield
    except Exception as e:
        self.state = AgentState.ERROR
        raise e
    finally:
        self.state = previous_state

执行循环控制

while (
    self.current_step < self.max_steps and
    self.state != AgentState.FINISHED
):
    self.current_step += 1
    step_result = await self.step()

    # 卡死检测
    if self.is_stuck():
        self.handle_stuck_state()

卡死检测机制

def is_stuck(self) -> bool:
    """检测Agent是否陷入循环"""
    if len(self.memory.messages) < 2:
        return False

    last_message = self.memory.messages[-1]
    if not last_message.content:
        return False

    # 检查是否有重复的assistant消息
    duplicate_count = sum(
        1 for msg in reversed(self.memory.messages[:-1])
        if msg.role == "assistant" and msg.content == last_message.content
    )

    return duplicate_count >= self.duplicate_threshold

当检测到卡死时,Agent会添加提示词引导改变策略:

def handle_stuck_state(self):
    stuck_prompt = (
        "Observed duplicate responses. Consider new strategies and avoid "
        "repeating ineffective paths already attempted."
    )
    self.next_step_prompt = f"{stuck_prompt}\\n{self.next_step_prompt}"

特殊工具处理

某些工具具有特殊语义,如Terminate工具会终止Agent执行:

async def _handle_special_tool(self, name: str, result: Any, **kwargs):
    if not self._is_special_tool(name):
        return

    if self._should_finish_execution(name=name, result=result, **kwargs):
        logger.info(f"Special tool '{name}' has completed the task!")
        self.state = AgentState.FINISHED

5.4 上下文感知与记忆管理

Memory机制

Memory类维护完整的对话历史:

class Memory(BaseModel):
    messages: List[Message] = Field(default_factory=list)
    max_messages: int = Field(default=100)

    def add_message(self, message: Message) -> None:
        self.messages.append(message)
        # 限制消息数量,保留最近的
        if len(self.messages) > self.max_messages:
            self.messages = self.messages[-self.max_messages:]

对话历史包含完整的交互序列:

User: "帮我创建一个Python脚本"
Assistant: [思考过程] [tool_calls: python_execute]
Tool: [执行结果]
Assistant: [分析结果] [tool_calls: str_replace_editor]
Tool: [文件创建结果]
Assistant: "脚本已创建完成"

上下文构建

Agent的上下文由三部分构成:

  1. 系统提示词:定义Agent的能力边界和角色
  2. 对话历史:包含用户请求、Agent思考、工具调用、工具结果
  3. 动态提示词:根据当前状态调整(如浏览器使用时的上下文)
async def think(self) -> bool:
    # 检查是否在使用浏览器
    browser_in_use = any(
        tc.function.name == BrowserUseTool().name
        for msg in recent_messages
        if msg.tool_calls
        for tc in msg.tool_calls
    )

    # 如果使用浏览器,添加浏览器上下文
    if browser_in_use:
        self.next_step_prompt = (
            await self.browser_context_helper.format_next_step_prompt()
        )

    return await super().think()

这种动态上下文调整使得Agent能够根据当前任务状态,提供更精准的决策。

六、架构图与数据流

6.1 Agent执行流程图

flowchart TD
    Start([开始]) --> Init[初始化Agent]
    Init --> SetState[设置状态为RUNNING]
    SetState --> CheckStep{检查步数限制}
    CheckStep -->|未超限| Think[think: 思考阶段]
    CheckStep -->|超限| Finish[终止执行]
    Think --> LLMCall[调用LLM.ask_tool]
    LLMCall --> ParseTool[解析工具调用]
    ParseTool --> HasTool{是否有工具调用?}
    HasTool -->|是| Act[act: 执行阶段]
    HasTool -->|否| CheckContent{是否有文本内容?}
    CheckContent -->|是| Continue[继续循环]
    CheckContent -->|否| Finish
    Act --> ExecuteTool[执行工具]
    ExecuteTool --> AddResult[添加结果到Memory]
    AddResult --> CheckStuck{检测是否卡死?}
    CheckStuck -->|是| HandleStuck[处理卡死状态]
    CheckStuck -->|否| CheckFinish{任务完成?}
    HandleStuck --> CheckFinish
    CheckFinish -->|未完成| Continue
    CheckFinish -->|完成| SetFinished[设置状态为FINISHED]
    Continue --> CheckStep
    SetFinished --> Finish
    Finish --> End([结束])

6.2 工具调用序列图

sequenceDiagram
    participant User as 用户
    participant Agent as Agent
    participant LLM as 大语言模型
    participant Tools as 工具集合
    participant Tool as 具体工具
    participant Memory as 记忆系统

    User->>Agent: 发送请求
    Agent->>Memory: 添加用户消息

    loop 执行循环
        Agent->>Agent: think()
        Agent->>Memory: 获取对话历史
        Agent->>LLM: ask_tool(历史+工具列表)
        LLM->>LLM: 分析上下文
        LLM->>LLM: 选择工具
        LLM-->>Agent: 返回工具调用决策
        Agent->>Memory: 添加Assistant消息

        Agent->>Agent: act()
        loop 遍历工具调用
            Agent->>Tools: execute(工具名, 参数)
            Tools->>Tool: 查找工具实例
            Tool->>Tool: 执行工具逻辑
            Tool-->>Tools: 返回结果
            Tools-->>Agent: 返回ToolResult
            Agent->>Memory: 添加Tool消息
        end

        Agent->>Agent: 检查是否完成
    end

    Agent-->>User: 返回最终结果

6.3 类继承关系图

classDiagram
    class BaseAgent {
        +name: str
        +memory: Memory
        +state: AgentState
        +run()
        +step()*
        +update_memory()
    }

    class ReActAgent {
        +think()*
        +act()*
        +step()
    }

    class ToolCallAgent {
        +available_tools: ToolCollection
        +tool_calls: List[ToolCall]
        +think()
        +act()
        +execute_tool()
    }

    class Manus {
        +mcp_clients: MCPClients
        +connect_mcp_server()
    }

    class BaseTool {
        <<abstract>>
        +name: str
        +description: str
        +parameters: dict
        +execute()*
        +to_param()
    }

    class ToolCollection {
        +tools: tuple
        +tool_map: dict
        +execute()
        +add_tool()
        +to_params()
    }

    class PythonExecute {
        +execute()
    }

    class BrowserUseTool {
        +execute()
    }

    BaseAgent <|-- ReActAgent
    ReActAgent <|-- ToolCallAgent
    ToolCallAgent <|-- Manus
    BaseTool <|-- PythonExecute
    BaseTool <|-- BrowserUseTool
    ToolCollection o-- BaseTool
    ToolCallAgent o-- ToolCollection

6.4 数据流图

flowchart LR
    subgraph Input[输入层]
        UserRequest[用户请求]
        SystemPrompt[系统提示词]
        ToolSchemas[工具Schema列表]
    end

    subgraph Processing[处理层]
        Memory[记忆系统]
        LLM[大语言模型]
        Agent[Agent核心]
    end

    subgraph Execution[执行层]
        ToolCollection[工具集合]
        Tool1[工具1]
        Tool2[工具2]
        ToolN[工具N]
    end

    subgraph Output[输出层]
        ToolResults[工具执行结果]
        FinalResponse[最终响应]
    end

    UserRequest --> Memory
    SystemPrompt --> LLM
    ToolSchemas --> LLM
    Memory --> LLM
    LLM --> Agent
    Agent --> ToolCollection
    ToolCollection --> Tool1
    ToolCollection --> Tool2
    ToolCollection --> ToolN
    Tool1 --> ToolResults
    Tool2 --> ToolResults
    ToolN --> ToolResults
    ToolResults --> Memory
    Memory --> FinalResponse

七、实践建议

7.1 如何设计新工具

设计新工具时,遵循以下原则:

  1. 清晰的工具描述description字段应该详细说明工具的用途、使用场景和限制
  2. 完整的参数定义:使用JSON Schema精确定义参数类型、约束和必需字段
  3. 错误处理:工具执行应该返回ToolResult,包含成功结果或错误信息
  4. 安全性考虑:对于执行代码、文件操作等敏感工具,需要添加权限检查和沙箱隔离

示例:设计一个文件搜索工具

class FileSearchTool(BaseTool):
    name: str = "file_search"
    description: str = (
        "Search for files in a directory tree matching a pattern. "
        "Supports glob patterns and regex. Returns list of matching file paths."
    )
    parameters: dict = {
        "type": "object",
        "properties": {
            "directory": {
                "type": "string",
                "description": "Root directory to search in (absolute path)",
            },
            "pattern": {
                "type": "string",
                "description": "Search pattern (glob or regex)",
            },
            "recursive": {
                "type": "boolean",
                "description": "Whether to search recursively",
                "default": True,
            },
        },
        "required": ["directory", "pattern"],
    }

    async def execute(
        self, directory: str, pattern: str, recursive: bool = True
    ) -> ToolResult:
        try:
            # 验证路径安全性
            if not Path(directory).is_absolute():
                return self.fail_response("Directory must be absolute path")

            # 执行搜索
            matches = await self._search_files(directory, pattern, recursive)
            return self.success_response({"files": matches})
        except Exception as e:
            return self.fail_response(f"Search failed: {str(e)}")

7.2 如何优化提示词

提示词优化是提升Agent性能的关键:

  1. 系统提示词

    • 明确Agent的角色和能力边界
    • 说明工作目录、可用资源等环境信息
    • 强调安全性和最佳实践
  2. 下一步提示词

    • 指导Agent如何分解复杂任务
    • 说明工具选择的原则
    • 强调结果验证和错误处理
  3. 工具描述

    • 使用具体、可操作的描述
    • 说明工具的限制和注意事项
    • 提供使用示例(在description中)

示例:优化后的系统提示词

SYSTEM_PROMPT = """You are OpenManus, a capable AI assistant.

Your capabilities:
- Execute Python code for data processing and analysis
- Browse the web to gather information
- Edit files using safe string replacement
- Interact with users when clarification is needed

Working directory: {directory}

Important guidelines:
- Always verify file paths before operations
- Use sandboxed execution for untrusted code
- Ask for confirmation before destructive operations
- Explain your reasoning at each step
"""

7.3 如何调试Agent行为

调试Agent需要系统化的方法:

  1. 日志记录:在关键节点添加详细日志

    • 思考阶段的LLM输入输出
    • 工具调用的参数和结果
    • 状态转换和错误信息
  2. 记忆检查:定期检查agent.memory.messages,验证对话历史的正确性
  3. 工具测试:单独测试每个工具,确保其行为符合预期
  4. 逐步执行:使用max_steps=1限制,逐步观察Agent的行为

示例:调试工具

async def debug_agent(agent: ToolCallAgent, request: str):
    """调试Agent执行过程"""
    print(f"Request: {request}")
    print(f"Available tools: {[t.name for t in agent.available_tools.tools]}")

    # 单步执行
    agent.max_steps = 1
    await agent.run(request)

    # 检查记忆
    print("\\nMemory contents:")
    for i, msg in enumerate(agent.memory.messages):
        print(f"{i}. {msg.role}: {msg.content[:100]}")
        if msg.tool_calls:
            print(f"   Tool calls: {[tc.function.name for tc in msg.tool_calls]}")

7.4 性能优化建议

  1. Token管理

    • 监控token使用量,避免超出限制
    • 对于长对话,考虑消息摘要或滑动窗口
    • 工具描述要简洁但完整
  2. 工具选择优化

    • 限制工具数量,只包含必要的工具
    • 使用工具分组,根据任务类型动态加载
    • 优化工具描述,提高LLM选择准确性
  3. 并发执行

    • 对于独立的工具调用,可以考虑并发执行
    • 注意工具之间的依赖关系
  4. 缓存机制

    • 缓存工具执行结果(如文件读取、API调用)
    • 避免重复执行相同的操作

示例:工具结果缓存

from functools import lru_cache
from datetime import datetime, timedelta

class CachedTool(BaseTool):
    _cache: Dict[str, Tuple[Any, datetime]] = {}
    _cache_ttl: timedelta = timedelta(minutes=5)

    async def execute(self, **kwargs) -> ToolResult:
        cache_key = str(sorted(kwargs.items()))

        # 检查缓存
        if cache_key in self._cache:
            result, timestamp = self._cache[cache_key]
            if datetime.now() - timestamp < self._cache_ttl:
                return result

        # 执行工具
        result = await self._execute_impl(**kwargs)

        # 更新缓存
        self._cache[cache_key] = (result, datetime.now())
        return result

八、总结

8.1 现代Agent的核心要素

通过深入分析OpenManus项目,我们总结出现代Agent系统的核心要素:

  1. 分层架构:基础层、思考层、工具调用层、应用层的清晰分离
  2. ReAct模式:推理-行动-观察的循环机制
  3. 工具系统:统一的工具接口和动态扩展能力
  4. LLM集成:通过function calling实现智能决策
  5. 状态管理:完善的状态机和执行控制
  6. 记忆系统:完整的对话历史管理

8.2 OpenManus架构的优势

OpenManus的架构设计具有以下优势:

  1. 可扩展性:通过BaseTool抽象,可以轻松添加新工具
  2. 可维护性:清晰的分层结构,职责明确
  3. 灵活性:支持静态和动态工具配置,支持MCP协议
  4. 健壮性:完善的错误处理和状态管理
  5. 可观测性:详细的日志和记忆系统

8.3 未来发展方向

现代Agent技术仍在快速发展,未来可能的方向包括:

  1. 多Agent协作:多个Agent协同完成复杂任务
  2. 长期记忆:超越对话历史的持久化记忆
  3. 工具学习:Agent自动发现和学习使用新工具
  4. 安全增强:更严格的权限控制和沙箱隔离
  5. 性能优化:更高效的token使用和并发执行

8.4 结语

构建现代Agent是一个系统工程,需要深入理解LLM能力、工具设计、系统架构等多个方面。OpenManus项目为我们提供了一个优秀的参考实现,展示了如何将理论转化为实践。

通过本文的系统性分析,我们希望读者能够:

  • 理解现代Agent的完整架构
  • 掌握工具系统的设计和实现
  • 了解Agent的思考和执行机制
  • 具备构建自己Agent系统的能力

现代Agent技术正在快速发展,期待更多开发者加入这个领域,共同推动AI Agent技术的进步。


参考资料

大模型虽已具备强大的感知与推理能力,但在面对复杂的计算机图形界面操作(Computer Use)任务时,仍受限于高质量数据稀缺与环境交互反馈缺失的双重挑战。美团技术团队推出了 EvoCUA 模型并在Github、Huggingface开源,通过构建可验证数据合成引擎与十万级并发的交互沙盒,将训练范式从传统的“静态轨迹模仿”转变为高效的“经验进化学习”。该方案在权威评测基准 OSWorld 上以 56.7% 的成功率刷新了开源 SOTA(2026年1月6日榜单),验证了基于经验的进化范式在 GUI 智能体领域的有效性。

01 背景与挑战

随着大模型的发展,AI 已经具备了强大的感知与推理能力。但在真实的使用场景中,我们希望 Agent 不仅能回答问题,更能解决问题——比如自动处理 Excel 表格、在浏览器中完成复杂的资料检索或跨应用协同。这种对解决问题能力的追求,推动了基础模型从 Chat(对话者)到 Agent(行动者) 的转变。

在这一进程中,Computer Use Agent(CUA,计算机操作智能体) 是一个关键里程碑。CUA打破了 API 的限制,构建了一种原生的交互方式——像人类一样,通过高分辨率视觉感知屏幕,并利用鼠标键盘完成跨应用的长链路任务,有可能成为下一代操作系统的核心交互入口。

然而,要训练出一个通用的 CUA,我们面临着严峻的数据扩展(Data Scaling)瓶颈。当前主流的训练范式依赖于对专家轨迹的模仿学习,但在将其推向工业级可用时,这种方式面临着三大挑战:

  • 数据合成质量低: 真实的高质量轨迹数据极度稀缺且昂贵,而试图用大模型直接生成数据往往会陷入“幻觉”。模型生成的指令或计划经常看似合理,但在真实的 UI 状态下根本不可执行。
  • 缺乏交互反馈: 静态数据模仿学习只能告诉模型“什么是对的”,却无法告诉它“如果点偏了会发生什么”。缺乏在大规模环境交互中产生的反馈,模型就无法捕捉操作与环境变化之间复杂的因果动态,难以适应真实环境中渲染差异、网络延迟等随机扰动。
  • 长链路探索效率低:计算机操作往往涉及数十步甚至上百步的连续决策,无约束的探索空间巨大且低效。仅靠简单的模仿学习,模型很难学会如何从中间的错误状态中反思并纠错。需要一种更高效和可扩展的范式,让模型专注于从海量自身成功和失败的经验里学习和进化。

面对上述挑战,我们正式推出了 EvoCUA, 一种原生的计算机操作智能体模型。EvoCUA致力于构建一种进化范式,让模型在大规模沙盒环境中,像生物进化一样,通过不断的试错,反思和修正,积累海量成功和失败经验,进而不断提升自身能力

通过这一范式,EvoCUA-32B 在 Computer Use权威的在线评测基准 OSWorld 上取得了 56.7% 的成功率,刷新了开源模型的 SOTA 记录,以更少的参数量和推理步数超过此前的开源SOTA OpenCUA-72B (45.0%),以及领先的闭源模型UI-TARS-2 (53.1%)。此外,实验证实该方案的通用性,在不同基座(如 Qwen3-VL、OpenCUA)及多个尺寸(8B 至 72B)的模型上均能显著提升 Computer Use 能力 。

模型上网查询如何配置rbenv开发环境并帮用户安装的示例:

02 核心技术架构

EvoCUA 的核心在于构建“交互-反馈-修正”的闭环。我们针对数据、环境、算法三个维度构建了自维持的进化架构:可验证数据合成引擎负责生产高质量任务,高并发交互基建支持海量轨迹合成,基于经验的迭代算法提供模型进化的关键路径。

2.1 可验证数据合成引擎

EvoCUA 数据层的核心任务是构建一个自动化流水线,能够合成覆盖各个垂直领域的高质量任务指令。我们要求合成数据要满足两个指标:

  • 场景完备性:覆盖从文档办公、Web 检索到系统管理的全场景操作。
  • 执行确定性:每一条数据必须在真实环境中可执行、可验证,杜绝逻辑幻觉。

在实现这一目标时,我们发现业界通用的“大模型生成 + Reward Model (RM) 筛选”范式在 Computer Use 场景下存在本质缺陷:

  • 语义与执行的割裂:传统的 RM 基于语义匹配打分,只能判断生成的指令在文本层面是否合理,无法验证其在物理层面能否执行。
  • Reward Hacking:模型倾向于生成逻辑通顺但包含“幻觉”的指令(例如点击不存在的 UI 元素)。这些不可执行的任务会引入大量训练噪音,导致模型在真实操作中产生严重的错误累积。

为了解决数据可信度问题,我们提出了 “生成即验证” 范式,在生成自然语言指令的同时,同步生成可执行的验证代码,并以沙盒中的实际运行结果作为判断数据是否有效的唯一标准。

整体数据合成框架如下:

2.1.1 结构化任务空间构建

在构建任务空间时,我们并未盲目堆砌数据,而是基于对 GUI 操作本质的两个核心洞见:

  • 原子能力的可迁移性与泛化性:GUI 操作虽然千变万化,但其底层的“原子技能”是跨域复用的。例如,“数据筛选”这一能力,无论是在 Excel、CRM 系统还是网页后台中,其逻辑内核是同构的。
  • 复杂任务的组合本质:真实世界中的复杂任务,本质上是由有限的原子能力通过特定逻辑编排而成的序列。掌握了原子能力的组合方式,就等于掌握了生成无限复杂任务的“语法”。

基于这两点思考,我们采用分层构建策略来初始化任务环境。

  • 原子能力拆解:我们将复杂的桌面操作任务解构为标准的原子能力单元。基于分层领域分类体系,例如将“Excel 财务分析”任务拆解为“公式计算”、“多列排序”、“透视表生成”等子技能。
  • 资源文件合成:为了模拟真实环境的复杂性,我们在环境初始化阶段实施了两种资源生成策略。

    • 参数化合成:针对结构化数据(如销售报表),我们利用代码生成器批量生产 Word/Excel 文档,随机化其中的姓名、价格、日期等参数。
    • 非参数化合成:针对非结构化数据,我们直接注入无版权问题的互联网上的公开资源(如真实的图片、音频、复杂的 PPT 幻灯片),强迫 Agent 处理真实世界中不可预知的视觉噪声和布局多样性。

2.1.2 指令和验证器合成

我们构建了基于 ReAct 的 Agentic 数据合成工作流。当给定一个场景元组(角色、能力、资源)后,作为任务架构师的基础 VLM 会启动生成:

  • 指令:生成符合用户意图的自然语言指令,确保任务目标清晰且在当前资源环境下可达成。
  • 验证器:同步生成对应的可执行验证Python验证代码以及标准答案(以文件/配置项等形式存在)。这段代码定义了任务成功的精确条件(例如:检查某个单元格的值是否为 X,或某个文件是否存在)。

不仅如此,我们还引入了沙盒执行反馈机制。生成的验证代码会立即在真实沙盒中运行。如果代码报错(如 API 错误、语法错误),错误日志会被回传给任务架构师进行自我修正。这个过程会迭代多轮,直到验证器本身能够成功运行并通过质量检查。

2.1.3 质量保障与去污

为了确保入库数据的纯净度,我们在数据落盘前设置了严格的过滤机制。

  • 一致性过滤:我们部署了一个测试Agent模型对合成任务进行试跑。通过比对“沙盒实际执行结果”与“验证器判定结果”,我们能精准识别出假阳性(False Positives)数据——即任务其实没做对,但验证器误判为成功的案例。只有那些经得起沙盒检验的数据才会被保留。
  • 三重去污染:用于合成数据的模型本身见过大量的预训练语料包含大量世界知识,大规模构造合成数据时,有混入和 Benchmark 有一定相关性的数据的风险。为了防止测试集泄露,我们实施了三重去污策略:

    • 语义去重:使用 LLM 过滤掉与 基准测试集在语义上高度相似的指令。
    • 配置去重:剔除与测试集具有相同初始化设置(如完全一致的文件名或窗口布局)的任务。
    • 验证器去重:检查生成的验证逻辑和 Ground Truth 文件,确保没有直接照搬测试脚本。

通过这套数据合成框架,我们成功将可验证的训练数据规模扩展到了数万量级,突破了人工标注的瓶颈。

2.2 支撑十万级沙盒并发的基础设施

EvoCUA 的进化范式要求 Agent 进行大规模的探索来合成经验轨迹。我们面临的挑战是工业级的:如何在一个集群中稳定调度 100,000+ 个每日活跃沙盒,处理百万级的分钟交互请求,同时保证每个环境的严格隔离与毫秒级响应。为此,我们构建了一套统一的环境沙盒平台,在调度吞吐与环境保真度两个维度做了大量优化。

2.2.1 微服务化编排

为了消除大规模强化学习中的 I/O 瓶颈,我们将传统的单体模拟器重构为基于微服务的异步架构。

异步 I/O 网关: 面对百万级交互请求,传统的阻塞式架构已无法支撑。我们采用了基于 Reactor 模式的异步非阻塞 I/O 设计网关架构,实现了 数百万 QPM(Queries Per Minute)的路由吞吐能力,并且将控制面(生命周期管理)与数据面(环境交互流)彻底解耦,确保长周期的环境执行(如打开一个重型 App)不会阻塞关键的路由逻辑,极大地提升了系统的吞吐上限。

沙盒批量急速启停: 强化学习的采样阶段具有极强的“脉冲”特性(短时间内需求激增)。我们的分布式调度器通过分片与资源池化技术,实现了极速冷启动能力。通过该优化,系统能够在 1 分钟内拉起 10,000+ 个沙盒实例。这种“即需即供”的弹性能力,确保了环境供给严格匹配训练需求,最小化了策略更新与经验采集之间的延时,保证了训练的高效流转。

2.2.2 保真环境构建

在解决了“量”的问题后,更关键的是“质”。Computer Use 任务对环境的确定性要求极高,微小的渲染差异或键位冲突都会导致模型训练非最优。

  • 混合虚拟化架构:为了兼顾容器编排的灵活性与虚拟机的强隔离性,我们采用了 Docker 容器嵌套 QEMU-KVM 的混合架构。

    • 外层:使用 Docker 对接 K8s 调度体系,复用美团成熟的容器化运维能力。
    • 内层:利用 KVM 硬件加速运行 QEMU 虚拟机。
    • 价值:这种设计既提供了内核级的安全隔离(防止 Agent 执行恶意代码穿透宿主机),又保证了接近原生的 GUI 渲染与 I/O 性能。
  • 操作系统级校准:标准 OS 镜像在自动化操作中存在诸多“隐形坑”,导致仿真环境与真实世界存在 Gap。为此,我们深度定制了 Ubuntu 22.04 镜像,实施了内核与用户态的双重补丁:

    • 输入确定性: 标准虚拟化常存在键位映射冲突(例如 US 键盘布局下 Shift + <状态丢失)。我们深入内核层修改了xkb的符号定义,确保 Agent 的符号意图与实际输入严格一致。
    • 渲染一致性: 视觉 Agent 对字体布局极其敏感。我们在系统层注入了全套专有字体库并强制刷新fc-cache,消除了文档在仿真环境与真实环境下的视觉渲染差异,防止模型因环境噪音而产生错误的视觉关联。

2.3 基于经验的学习范式

有了可验证的数据和高吞吐的环境,我们的核心目标是如何让模型像人类一样学习:要在大量的自我实践中巩固成功经验,并从失败中吸取教训。然而,单纯依赖静态数据的监督微调存在两个本质缺陷:

  • 分布偏移:训练数据的分布往往是“完美路径”,而推理时的环境充满了随机性。模型一旦偏离了专家轨迹,就不知道如何回到正轨。
  • 负反馈缺失:SFT 只能告诉模型“怎么做是对的”,却从未告诉它“怎么做是错的”以及“错在哪里”。

EvoCUA 提出了一种渐进式的进化范式,将训练过程解耦为三个阶段:冷启动(注入先验思维模式)、拒绝采样微调(动态算力分配,巩固成功经验)、强化学习(聚焦关键出错点,从失败经验中学习)。

2.3.1 Cold Start: 冷启动

在让 Agent 进入大规模环境进行自由探索之前,给模型注入一些思维pattern,能够提高模型的有效探索能力。为了摸清当前 Agent 能力的边界,我们深入分析了 Qwen3-VL-Thinking、OpenCUA-72B 等主流模型推理轨迹。我们发现,各家模型均有一定缺陷。例如:OpenCUA-72B 很容易提前误判成功,而Qwen3-VL模型在动作空间上存在一些明显缺失(如不支持Shift+Click)。基于此,EvoCUA 在冷启动阶段的核心任务,是定义一套完备的动作空间与严谨的思维范式。

  • 完备的动作空间:处理复杂操作,如 Excel 中的 Shift + Click。如果是原子的press操作,无法表达这种持续按压的状态。为此,我们将按键拆分为key_downkey_up
  • 结构化思维链:为了避免“幻觉”和“伪成功”,我们给模型注入了一些像人类一样的优秀思维范式:

    • 目标澄清:在初始时刻,强制模型复述并拆解用户意图,消除指令歧义。
    • 观测一致性:简短且精准,严格对齐当前的视觉元素,防止“看图说话”时的幻觉。
    • 自我验证:在发出Terminate信号前,模型必须执行显式的检查步骤。例如在发完邮件后,进入“已发送”文件夹确认,而非盲目自信。
    • 反思与纠错:针对采集到的失败轨迹,我们识别出状态偏离的关键分岔点,从错误发生后的那一步恢复环境状态,通过 Prompt 引导和高温采样让模型自我修正。
    • 终止判断Terminate动作必须强依赖于前序的 CoT 论证。如果思维链中没有明确的完成证据,模型不得输出结束信号,以此抑制“伪成功”。
  • 后见之明数据合成:在训练数据构造上,我们不直接使用模型的原始 CoT。对于成功轨迹,我们采用“后见之明”策略——基于正确的 Action 序列反向重写逻辑严密的思维链;同时混入不可完成任务,教会模型识别环境边界,学会说“No”。

经过冷启动训练后,模型展现出了明显的行为范式转变。它不仅掌握了终端和复杂快捷键的操作,更重要的是学会了“慢思考"——在关键节点进行校验和反思。这为后续的大规模进化提供了坚实的原子能力基础。

2.3.2 RFT:拒绝采样微调

冷启动赋予了模型基础的原子能力,接下来的挑战是如何在万级 Query 上进行 Scaling。我们面临的核心权衡是:如何在有限的算力预算下,最大化高质量经验的产出效率与信噪比?如果对所有任务平均用力,会导致简单任务算力浪费,而困难任务探索不足。为此,EvoCUA 设计了一套“阶梯式动态算力分配 + 步级别去噪”的拒绝采样微调策略。

阶梯式动态算力分配:为了最大化探索的 ROI,我们将 Query 池划分为不同难度层级,并实施阶梯式的 Rollout 策略。我们将采样次数 K 划分为多个档位 {3, 8, 16, 32, 64},并为每个档位设定了成功率阈值(如 100%, 75%, 50%...):

  • 自适应爬坡:模型从低 K 档位开始尝试。如果在当前档位的成功率达到了预设阈值(说明模型已掌握),则立即停止采样;反之,若成功率较低,则自动升级到下一档位,投入更饱和的算力进行攻坚。
  • 边界突破:这种机制确保了算力被集中投放到模型处于能力边界的困难任务上,而非在已熟练的任务上重复“造轮子”。

步级去噪:模型生成的原始轨迹即使成功了,也往往包含大量噪声(如无效的鼠标滑动)。直接学习这些数据会污染模型。我们实施了精细化的清洗策略:

  • 冗余和错误步骤过滤:利用 Judge Model 分析成功轨迹,识别并掉对最终结果无贡献的冗余步骤,显著提升了数据的信噪比。
  • Infeasible 任务特判:针对不可完成的任务,成功的轨迹往往伴随着大量的无效尝试后才终止。对于这类数据,我们仅保留最后一步(即正确输出Terminate=Failure 及对应的推理),将中间所有的试错步骤全部剔除。

通过 RFT,我们将大规模的合成经验内化为模型参数,显著提升了模型在常规路径的执行成功率。

2.3.3 RL:强化学习

RFT 夯实了模型在常规路径上的执行成功率,但面对长链路任务中的环境扰动(如弹窗、网络延迟、布局微变),模型依然脆弱。相比于成功轨迹中模型已有的知识,失败轨迹中蕴含着广阔的、非线性的树状结构信息,模型往往会在一些关键步骤出错,正是模型能力边界的直接体现。

传统的 RL 算法通常以整条轨迹为粒度,存在严重的信用分配难题——几十步的操作中可能只有一步是错的,全盘否定会导致有效经验被浪费。

为了解决这一问题,我们提出了一种面向Computer Use的高效DPO算法,将优化粒度从“轨迹级”下钻到“关键分岔点” , 重点解决模型在出错边缘的能力边界感知问题。

关键分岔点挖掘:在长达数十步甚至上百步的 GUI 操作中,任务失败往往具有滞后性。模型可能在第 5 步做出了一个微小的错误决策(如选错了筛选条件),但直到第 30 步才因为找不到目标文件而报错。为了精准定位错误,EvoCUA 提出了一种基于参考导向的归因机制——关键分岔点挖掘。 我们利用同一 Query 下的“成功轨迹”与“失败轨迹”进行对齐分析。系统会自动定位到状态一致但动作开始偏离的那一帧,记为关键分岔点。

双范式偏好对构建:一旦通过因果诊断锁定了关键错误,我们并未止步于简单的行为克隆,而是针对出错瞬间”和“出错之后”两个不同的时空切片 , 构造了两种截然不同的 DPO 偏好范式,从而在一次训练中同时兼顾了准确性与鲁棒性。

  • 范式一:动作修正,此范式聚焦于“即时纠错”,旨在教模型在关键分岔点(t时刻)必须“走正道”。我们将导致后续失败的原始错误动作作为负样本;对于正样本,我们优先尝试通过 VLM 语义匹配,将成功参考轨迹中的“正确思考与动作”迁移过来。如果参考轨迹无法对齐,则调用VLMs模型基于当前视觉状态合成全新的正确动作。
  • 范式二:反思与恢复,此范式聚焦于“错误恢复”,旨在提升模型在错误发生后(t+1 时刻)的反思修正能力。在这一时刻,环境状态通常已经因为前一步的错误而发生了偏离(如出现了预料之外的弹窗)。我们把模型无视环境变化、机械执行原计划的“盲目继续”行为标记为负样本;同时,利用 Prompt工程引导模型生成一条“反思链”作为正样本——即教导模型在发现状态异常时,优先选择停下来,观察屏幕异常并重新规划,而不是一条道走到黑。

通过这两个范式的结合,模型不仅教会了 Agent 如何做对,更教会了它在做错或环境突变时如何反思修正。随着能力的不断提升,上述RFT和DPO可以进行多轮迭代训练。

除了DPO,我们在实践中还探索了online RL,通过主动的环境交互,模型表现出了持续的奖励增长趋势,会在下一个版本的模型中更新。

总而言之,我们通过“双重机制”将海量的合成经验高效内化为模型参数:一方面利用 RFT 来夯实基础的执行范式,确保模型在标准任务上的发挥稳定;另一方面利用 RL在复杂的长尾场景中主动纠错,显著提升模型在能力边界上的鲁棒性与泛化力。

03 实验评估

为了验证 EvoCUA 范式的有效性,我们在权威在线榜单OSWorld上进行评测。实验的核心结论如下:EvoCUA-32B 以 56.7% 的成功率刷新了开源模型 SOTA,并在同等推理预算(max step=50)下逼近了闭源模型 Claude-4.5-Sonnet (58.1%) 的水平;同时验证了该进化范式在不同规模模型上的普适性。

3.1 OSWorld 评测

  • 开源SOTA:我们的主力模型 EvoCUA-32B(基于 Qwen3-VL-32B-Thinking 后训练)达到了 56.7% 的成功率。这一成绩大幅领先此前的开源 SOTA(OpenCUA-72B, 45.0%)。值得注意的是,EvoCUA-32B 超越了闭源强基线 UI-TARS-2-2509 (53.1%)。在严格限制 50 步 推理预算的同等条件下,我们与行业顶尖的 Claude-4.5-Sonnet (58.1%) 差距缩小至仅 1.4%。
  • 小参数大潜力:EvoCUA-8B 同样表现惊艳,以 46.1% 的成功率击败了 OpenCUA-72B。与同样基于Qwen3-VL-8B训练的Step-GUI-8B (40.2%) 相比,EvoCUA-8B 取得了 +5.9% 的显著优势。

3.2 消融实验

为了探究 EvoCUA 性能提升的来源,我们进行了逐层拆解的消融实验。

  • 统一动作空间 (+4.84%):通过完善动作空间带来的提升。
  • 冷启动(+2.62%):注入高质量的行为先验,确立了思维与行动的对齐。
  • RFT 拒绝采样(+3.13%):通过动态算力巩固成功经验,在不损失pass@k能力基础上,提升模型的pass@1能力。
  • Offline DPO(+3.21%):针对关键分岔点的纠错训练,显著提升了模型鲁棒性。
  • 迭代训练(+1.90%):再进行一轮迭代训练,性能持续增长。

3.3 Scaling分析

我们进一步验证了 EvoCUA 的 Scaling Law。

  • Max Step:随着推理时步数的增加,我们观察到模型的性能在不断提升。但由于我们数据中超过50步的样本较少,因此大于50步的边际收益收窄。
  • Pass@k:随着采样次数k的增加,EvoCUA 始终保持对初始化模型的显著优势。这表明优化后的 Policy 具有更高的天花板。
  • 数据规模:在 RFT 阶段,我们将数据量从 20k 扩展到 1M,观察到了持续的性能爬坡。

3.4 轨迹可视化分析

我们随机抽样一条合成指令任务,对训练后的模型采样轨迹进行可视化。以一个电子表格任务为例:“找出每行的最大值并填入 G 列”,以下是EvoCUA-32B在四个关键时刻的思考与执行过程:

Step 1:目标澄清,智能体显式复述并拆解了用户指令。

Step2:智能体使用excel公式原子能力Max操作。

Step 9:有状态鼠标交互,专业软件操作常涉及“按住并点击”等组合动作。智能体执行“Shift+点击”操作以选中 G3 到 G11 的数据范围。

Step 15:审慎终止判断,智能体没有盲目停止,而是先生成视觉证据:“我看到 Max 列已计算完毕...”。只有在视觉核验结果符合初始指令后,它才发出terminate信号,确保任务完成。

04 总结展望

EvoCUA,一个基于经验进化范式的原生 Computer Use Agent。通过可验证的合成引擎、可扩展的交互基建和可进化的经验学习算法,我们探索出一条提升Computer Use能力的通用方法。在 OSWorld 基准测试中,EvoCUA 以 56.7% 的成功率刷新了开源模型的 SOTA,证明了这条路径的有效性。在超过 100 万卡时的上千组实验中,我们总结了四条关键的洞察,希望能为社区提供参考:

  • 高信噪比数据是关键: 成功轨迹是低噪声但低信息量的,失败轨迹是高噪声但高信息量的。如何处理好数据,保证较高的信噪比是模型能力持续提升的关键。
  • 先验 Pattern 重于数据量:冷启动阶段,Pattern 的多样性远比数据量重要。一个轻量级但覆盖全原子能力的冷启动,比大量低质量数据的 SFT 更能为后续的 RL 打好基础。
  • On-Policy 的重要性:在长链路任务优化中,要严格使用 On-Policy 数据。一旦过度使用 Off-Policy 数据,会导致优化方向偏离原始模型主分量,且较难恢复。
  • 可视化驱动的迭代:数据和算法之外,我们开发了大量用于轨迹可视化和 Debug 的分析工具,一套全流程可视化诊断工具对于数据质量校验、轨迹对比分析和问题发现至关重要。

尽管取得了阶段性突破,我们必须承认,当前开源模型与顶尖闭源系统(及人类水平)之间仍存在显著差距。这一差距揭示了单纯依赖离线合成轨迹的性能天花板。我们认为,打破这一瓶颈的关键在于在线强化学习。我们初步的实验信号显示,通过主动的环境交互,模型表现出了持续的奖励增长趋势。未来的工作将聚焦于系统性地拓展这一在线进化边界,最终实现完全自主的计算机操作能力。

目前,EvoCUA 现已全面开源,欢迎访问项目主页获取更多信息:

| 关注「美团技术团队」微信公众号,阅读更多技术干货!

| 本文系美团技术团队出品,著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容,敬请注明“内容转载自美团技术团队”。本文未经许可,不得进行商业性转载或者使用。任何商用行为,请发送邮件至 tech@meituan.com 申请授权。

引言:2026,不是 AI 更聪明,而是企业第一次“让权”

过去几年,人工智能在企业中的角色更多停留在边缘助手创意补充: 生成报告、分析数据、辅助人类判断。

2026 年正在发生的变化本质不同—— AI 首次被系统性地引入封闭业务环(Closed Business Loop),开始承担决策—执行—反馈的完整责任。

这不是一次工具升级,而是一次生产力控制权的转移

一、决策中枢的重构:从“分析支持”到“处方式治理系统”

1. 核心定义:处方式分析(Prescriptive Analytics)

处方式分析指的是:

AI 系统在预测未来结果的基础上,结合业务目标、资源约束与规则边界,直接输出可执行决策,并对决策逻辑负责

这标志着 AI 从“建议者”转变为“处方制定者”。

2. 核心场景:动态供应链的自主编排

在制造业与零售业中,AI 智能体正在接管传统由人类审批的关键节点:

  • 实时感知全球物流与原材料价格
  • 自动调整采购规模与供应商组合
  • 重规划运输路径
  • 在需求激增时,无需人工确认直接触发增产

变化的关键不在于速度,而在于“洞察 → 行动”的零延迟闭环。 企业的核心矛盾,第一次被交由算法持续调解。

二、生产力的原位升级:从 RPA 到智能体工作流

1. 核心定义:Agentic Workflow(智能体工作流)

智能体工作流是指:

由多个具备感知、推理、规划与工具调用能力的 AI 智能体,分别接管业务流程节点,并通过协议协作形成的自运行系统。

与传统 RPA 不同:

  • 无需硬编码路径
  • 可在异常中自我修正
  • 不依赖人类实时监控

2. 核心场景一:软件工程的“无人维护阶段”

在成熟企业中,AI 已进入核心代码库的长期演进流程:

  • 自主编写与维护测试用例
  • 自动定位回归缺陷
  • 提交可审计的修复补丁
  • 优化架构而非仅“修 bug”

3. 核心场景二:金融与合规的实时智能审计

AI 智能体可对每一笔交易进行:

  • 法规语义级匹配
  • 内控规则比对
  • 异常模式识别并在风险出现前自动冻结或上报流程

在实际落地中,一些企业并不会从零构建智能体体系,而是选择成熟的平台基础设施。 例如 「智能体来了」(https://agentcome.net/,为非技术密集型企业提供了将 AI 嵌入财务、法务与运营核心流程的可行路径,实现“降人力密度”的同时,提升系统稳定性。

三、知识资产的激活:从静态文档到“可推理经验”

1. 核心定义:企业级神经知识库(Enterprise Neural Knowledge Base)

它并非传统意义上的知识管理系统,而是:

将企业历史数据、行业经验与大模型推理能力深度融合,使 AI 能够理解企业“为何如此运作”。

经验不再依赖个人,而被转化为可调用的逻辑结构

2. 核心场景:研发(R&D)的认知加速

在医药、新材料等领域,AI 已从“数据分析者”变为:

  • 实验设计者
  • 模拟路径规划者
  • 研发策略的动态调整者

通过对实验反馈的持续建模,AI 正在压缩原本以“年”为单位的研发周期

四、总结:2026 年之后,企业竞争的真正变量

形态转变 AI 不再是对话框里的助手,而是业务后台的数字执行官

价值逻辑 真正的效率红利,来自 AI 在高复杂度、强约束场景中的持续决策能力。

长期视角 未来企业的竞争,将是“知识模型化程度”的竞争。 谁能率先将不可见的经验转化为可协作的智能体网络,谁就拥有更低的组织摩擦成本。

这不仅是技术普及, 更是一场企业管理范式的重排

大家好,我是R哥。

最近 Claude Skills 又开始爆火了,几个月前我分享《MCP 不香了,Claude Code 又推出了 Skills!!(保姆级安装和使用教程分享)》时还是不温不火,现在已经火爆全网了。

经过几个月的发展,Skills 也有了些许变化,这篇我再结合最新的信息,分享下 Skills 的概念及如何在 Claude Code、CodeX、OpenCode 中创建和如何 Skills。

万字干货,避免错过,建议收藏慢慢看。。

Skills 是什么?

Skills 最初由 Anthropic 公司开发,专门用来扩展 Claude 功能的模块化能力

说白了,Skills 其实就是一个文件夹,这是每个 Skills 的目录结构:

my-skill/
    ├── SKILL.md          # 必选:指令、元数据
  ├── scripts/          # 可选: 执行脚本
  ├── references/       # 可选:参考文档
  └── assets/           # 可选:模板、资源

每个 Skill 包含指令、元数据和资源等,只有当 Claude 认为某个 Skill 和当前任务相关时,它才会启用,即按需加载,从而提升性能,也能大大节省 Tokens 消耗。


现在 Anthropic 已经把 Skills 做成《Agent Skills》开放标准了:

https://agentskills.io/

这是一个 Skills 开放标准,由 Anthropic 发布并推动作为开放标准,旨在让不同 AI 平台都能实现一个通用的 “Agent Skills” 格式。

Anthropic 真是 AI 标准的制定者,前有 MCP 协议,现在又弄出了 Agent Skills 标准。

Agent Skills 现在已经被主流的 AI 开发工具全面支持了,我看 OpenAI、Google、Cursor 等 AI 厂商都已经跟进并支持 Skills 了。

比如,我刚在 Claude 写完 Skills,直接就可以复制到 CodeX 中使用,100% 兼容。

Skills 的架构

Skills 在代码执行环境中运行,它具有文件系统访问、bash 命令和代码执行功能。

这是 Skills 的架构图:

可以这样理解,Skills 相当于是虚拟机上的目录,Claude 可以使用计算机上导航文件相同的 bash 命令与它们交互。

Skills 的工作原理

Skills 是通过渐进式披露来高效管理上下文,这张图演示了 Claude 如何加载和使用 PDF 处理 skill 的方式:

这种动态加载方式,确保只有相关的 Skill 内容占据上下文窗口。

工作流程

第 1 步:发现 Skills(始终加载)

Claude 在启动时,代理只会加载每个可用技能的 SKILL.md 中的元数据,比如:名称和描述,用来判断它什么时候可能用得上。

元数据格式如下:

---
name: pdf-processing
description: 从 PDF 文件中提取文本和表格、填充表单、合并文档。在处理 PDF 文件或用户提及 PDF、表单或文档提取时使用。
---

这种轻量级的加载方式,意味着我们可以集成大量的 Skills 而不会产生上下文成本,Claude 只知道每个 Skill 的存在以及何时使用它。

第 2 步:激活 Skills(触发时加载)

当任务匹配到某个技能的描述时,代理才会把完整的 SKILL.md 指令加载进上下文里。

参考指令如下:

# PDF 处理

## 快速入门

使用 pdfplumber 从 PDF 中提取文本:

```python
import pdfplumber

with pdfplumber.open("document.pdf") as pdf:
    text = pdf.pages[0].extract_text()
```

有关高级表单填充,请参阅 [FORMS.md](FORMS.md)。

SKILL.md 的指令包含 Skills 的运行逻辑,包括它的:工作流、最佳实践和规范等,其实就是一个提示词说明书文档。

第 3 步:执行 Skills(按需加载)

代理会按照 SKILL.md 中的指令来操作,必要时还会加载 references 目录中引用的文件,或者运行 scripts 目录下打包好的脚本及代码。

Skills 通过渐进式披露这种方式,可以让代理按需调取更多上下文,从而执行得飞快。

渐进式披露成本

渐进式披露确保任何给定时间,只有相关内容占据上下文窗口,这是它的成本:

步骤加载时间令牌成本
第 1 步:发现始终加载每个 Skill 约 100 个令牌
第 2 步:激活触发时加载不到 5k 个令牌
第 3 步:执行按需加载实际上无限制

SKILL.md 的文件结构

每一个 Skill 都必须要有一个 SKILL.md 文件,它是一个 Markdown 格式的文件,包含 YAML 前置元数据和 Markdown 指令。

参考格式如下:

---
name: your-skill-name
description: 简要描述此 Skill 的功能以及何时使用它
license: Apache-2.0
metadata:
  author: example-org
  version: "1.0"
---

# Skill 名称

## 指令
[Claude 要遵循的清晰、分步指导]

## 示例
[使用此 Skill 的具体示例]

SKILL.md 的顶部,必须加上前置元数据,主要是 namedescription 这 2 个元数据,其他的都是可选的。

字段是否必填约束条件
name最多 64 个字符;只能包含小写字母、数字和连字符;不能以连字符开头或结尾。
description最多 1024 个字符;不能为空;用于描述该技能的功能以及适用场景。
license许可证名称,或指向随技能一起提供的许可证文件的引用。
compatibility最多 500 个字符;用于说明环境要求,例如目标产品、系统依赖、网络访问等。
metadata用于附加元数据的任意键值映射。
allowed-tools技能可使用的预批准工具列表,以空格分隔(实验性功能)。

另外,Markdown 中的实际指令,对结构和内容没有特别限制

如下面这个示例:

---
name: pdf-processing
description: 从 PDF 文件中提取文本和表格,填写表单,合并文档。
---

# PDF 处理

## 何时使用该技能
当用户需要处理 PDF 文件时,使用该技能……

## 如何提取文本
1. 使用 pdfplumber 进行文本提取……

## 如何填写表单

...

这种简单的格式有几个关键优势:

  • 清晰易懂:不管是技能作者还是使用者,只要看一眼 SKILL.md ,就能明白它干啥的,让技能的维护和优化变得特别轻松。
  • 扩展性好:技能的复杂度可以灵活调整,从简单的文字指令,到可执行代码、资源文件,再到模板,全都能搞定。
  • 轻松迁移:技能就是个文件,编辑、版本管理、分享都特别方便。

相比于固定的 AI 工作流,Skills 的灵活性更好。

Skills 仓库推荐

在使用 Skills 前,先分享两个 Skills 仓库:

第一个是官方的 Skills 仓库,里面包含了一些图片、文档等基本技能,还有一个 skill-creator 技能,通过它就可以引导式创建一个技能。

第二个是第三方的 Skills 仓库,里面也包含也许多类型的技能,根据自己的需要酌情使用。

还有更多一些大厂、第三方收集的 Agent Skills,这篇就不展开了,下一篇会详细分享一下,关注公众号「AI技术宅」第一时间分享。

Claude Code 使用 Skills 指南

拿 Claude 自家来说,Claude API、Claude Code、Claude Agent SDK 等都支持 Skills,下面以 Claude Code 为例,来看看要怎么创建和使用 Skills。

Claude Code 的安装和高级用法看这两篇:

Skills 分类

技能的存储位置决定了谁可以使用它:

Skills 类型含义说明生效范围目录位置
Personal Skills个人技能,所有项目都可以复用的 Skills全局(对所有项目生效)~/.claude/skills/
Project Skills项目技能,仅对当前项目生效,便于团队协作与共享单个项目.claude/skills/
Plugin Skills插件技能,随插件一起安装,安装后即可直接使用取决于插件适用范围由插件定义(安装后自动生效)

一般是全局、项目 Skills。

安装 Skills

比如,你想使用官方、第三方的 Skills,只需要把它们仓库的技能目录复制到 ~/.claude/skills 目录下即可:

在 Claude Code 中使用 /skills 指令就可以列出所有的技能。

使用 Skills

使用 Skills 有两种方法:

1、自动引用

上面说了,如果 Claude 认为你的需求和某个 Skill 相关时,它就会自动加载并使用。

比如我发送:

列出所有skills并创建一个pdf

提示词中要创建 PDF,所以它自动加载了 PDF 的 Skill,这就是自动按需加载。

2、手动引用

你也可以通过 /xx 来手动引用要使用的 Skill,比如我明确知道官方有一个 canvas-design 技能,那我可以这样手动引用:

/canvas-design 设计一个 AI 学习路线图

如果你知道某个经常用的 Skills,这样手动引用可能会加快 Skills 的加载速度。另外,如果有多个类似的 Skills,手动引用也特别有用,避免用错。

创建自定义 Skills

创建 Skills 非常简单,一个 3 步:

  • ~/.claude/skills 目录下创建一个技能目录;
  • 在技能目录下面创建一个 SKILL.md 技能文档;
  • 开始编写你的 SKILL.md 文档具体操作指令。

当然,你也可以通过官方的一个 skill-creator 技能来引导式创建 Skills,这种方式更快,创建出来的 Skills 也会更懂你的需求。

下面,我来演示下如何通过 skill-creator 技能来创建一个自媒体助手 Skills。

然后,我把我在 GPT 上面的提示词扔给它:

当然,不一定要提供提示词,你完全可以把你的需求说出来,让它一步步帮你构建好这个 Skill。

不一会儿,它就帮我在 ~/.claude/skills 目录下创建好了 my-zmt-tools 自媒体助手 Skill,它主要包括两个功能:中文转英文URL、内容转小红书风格,这两个功能我之前是在 GPT 上面实现的。

使用 /skills 指令来验证下:

有了,这是它生成的 SKILL.ms 文档:

还不错吧?如果不满意,还可以基于它做二次修改。

现在来看看如何使用它,直接使用 /my-zmt-tool 技能的指令,然后带上指令参数、具体的内容或者要求就行了:

成功了,中文标题正确转换成了英文 URL,这个功能我在写博客时经常要用到,比如《MCP 不香了,Claude Code 又推出了 Skills!!(保姆级安装和使用教程分享)》这篇文章就对应这个 URL:

https://www.javastack.cn/claude-code-skills-usage/

后面的 claude-code-skills-usage 就是靠定制化 GPT 帮我生成的。

在使用 ChatGPT 时,首先要切换到具体的 GPT,然后再发送指令,使用不是很方便,网络慢时可能更影响速度,现在有了 Skills 感觉效率要更快了。

所以,有了 Skills,很多 GPT 上面完成的工作,都可以尝试用 Skills 来完成,Skills 有了更多的可能性。

CodeX 使用 Skills 指南

上面说了,Agent Skills 已经是开放标准了,在 Claude 创建好的 Skills 也可以在其他支持 Agent Skills 的 AI 编程工具中使用,比如 CodeX。

方法很简单,比如,我把上面创建好的 my-zmt-tolls 目录直接复制到 ~/.codex/skills 目录下。

然后同样使用在 CodeX 中使用 /skills 命令,可以列出所有的 Skills:

用法其实和 Claude Code 差不多,不太一样的是,Claude Code 的自身命令、斜杠命令和 Skills 都是通过 / 来选择,非常混乱,而在 CodeX 中,Skills 可以使用单独的 $ 来选择 Skills,它是和自身的 / 命令分开的。

所以,在 CodeX 中可以自动调用 Skills,也可以手动指定要引用的 Skill:

Skill 都正常执行了,很方便吧?

/skills 列表命令也可以看到,CodeX 还提供了一个 skill-creator 命令用于创建和维护 Skills,还有一个 skill-installer 命令用于从其他仓库源安装 Skills。

其他支持 Skills 的 AI 编程工具,都是同一样的手法。

OpenCode 使用 Skills 指南

如果你有多模型的使用习惯,比如:国外、国内、本地模型混用,封闭的 Claude Code、CodeX 就无法满足需求了,这里我们就得使用最近火爆全网的 OpenCode,号称开源版的 Claude Code,它支持任意模型随时切换。

现在越来越多的人都在使用 OpenCode,包括我自己。

怎么安装和使用参考我分享的使用教程:

开源版 Claude Code 杀疯了,怒斩 70k+ Star!!

OpenCode 会自动搜索以下位置的 Skills:

  • 项目配置:.opencode/skills/<name>/SKILL.md
  • 全局配置:~/.config/opencode/skills/<name>/SKILL.md
  • 兼容项目 Claude:.claude/skills/<name>/SKILL.md
  • 兼容全局 Claude:~/.claude/skills/<name>/SKILL.md

也就是说,OpenCode 不需要像 CodeX 那样复制 Skills,它支持自动搜索 Claude 的 Skills,这就比 CodeX 要方便太多了,不用复制冗余文件,这太舒服了。

目前,OpenCode 官方还没有类似 的 /skills 命令来列出所有的 Skills,不过可以通过问它列出所有的 Skills:

使用方法也是一样的,可以自动或者手动引用 Skills:

OpenCode 桌面版的使用也是一样的。

常见问题

经过以上 Skills 的工作原理和使用指南,下面的问题就不是问题了。

1、有了 MCP,为什么又搞出 Skills?

之前分享了一篇 MCP 的介绍及使用:

最近热火朝天的 MCP 是什么鬼?如何使用MCP?一文给你讲清楚!

MCP 本质上是为 AI 大模型提供调用外部工具的能力,MCP Server 就是这个能力的具体实现——你可以通过它,把你已有的 API、脚本、服务包装成 AI 能理解和调用的 MCP 工具。

使用 MCP 的限制:

  • 如果只靠 MCP,你虽然可以调用很多工具/数据,但模型每次必须在提示或上下文里夹带大量相关信息,这会消耗大量 token、降低效率。
  • 在很多场景下,问题不是调用 API,而是按公司标准/流程来做事,MCP 可以访问数据或工具,但不会自动知道这个流程的外在规则是什么。

而 Skills 正好解决了这些问题,所以,MCP 是 AI 连接外部的工具,而 Skills 教模型如何使用工具。

MCP + Skills 可以协同工作,在很多复杂系统中,两者往往组合使用,模型先通过 MCP 访问工具/数据,再通过 Skills 引导流程执行

但有一点,在执行代码方面:

Skills 虽然也支持代码执行,但受限于本地的环境,比如执行 Python 脚本,要是本地没有安装 Python 环境,或者版本不兼容,都会影响 Skills 执行效率。

MCP 因为是执行固定的代码,所以 MCP 在执行代码方面要更稳定

2、Skills 和 Slash Commands 有什么区别?

Skills 是由模型驱动的,Claude 会根据你的任务和 Skill 的描述自动匹配并使用这些 Skills,完全不需要你介入,当然也可以通过 /skill-name 来主动触发。

Slash Commands(斜杠命令)则是完全由用户触发的,你需要主动输入 /command 才能触发。

但是,从最新的 Skills 来看,Slash Commands 也被合并在用户 Skills 中了:

合并归合并,困为 Slash Commands 和 Skills 两者都可以通过 / 手动触发,Slash Commands 并不能自动触发,因为它没有像 Skills 那样定义元数据。

Skills 相比 Slash Commands 只是多了几个可选功能,它支持文件的目录、控制 Claude 是否调用 Skills 前置元数据,以及 Claude 在相关时自动加载它们的能力。

总结

Agent Skills 这一套机制,表面看只是多了一个 SKILL.md 文件,实际上背后是一整套 Agent 能力组织方式的升级

Agent Skills 把提示词、工具、脚本、资源全部收敛到一个标准化目录里,再通过「渐进式披露」的方式按需加载,这一点对上下文成本和执行效率的提升非常明显。

从使用体验来看,Skills 最大的价值有三个:可复用、低心智成本、易迁移

不管是个人常用能力,还是项目级、团队级的能力,都可以沉淀成 Skills,一次写好,反复使用。而且它不绑死某一家平台,已经被做成开放标准,Claude、Google、OpenAI、Cursor 都能用,这一点非常重要。

比如拿我自己来说,以前要频繁切 GPT,现在一个 Skill 就能搞定。

所以,可以预见的未来,Agent Skills 的体系和生态会更加完善,大家可以早点把自己的常用能力沉淀下来,后面只会越用越爽。

未完待续,R哥持续分享更多 AI 编程经验,包括更加复杂的 Skills 使用,公众号第一时间推送,关注和我一起学 AI。

⚠️ 版权声明:

本文系公众号 "AI技术宅" 原创,转载、引用本文内容请注明出处,抄袭、洗稿一律投诉侵权,后果自负,并保留追究其法律责任的权利。

今天发现京东数码海外自营旗舰店售卖的 pixel 10 手机的充电功率标错了,实际只有 30W 他们标成了 65W ,我问客服他们是不是标错了客服还说以商品详情页面为准,感觉这已经构成虚假宣传了,就是不知道海外发货的商品能不能退一赔三,如果确定能对话我都想操作一波了。





https://npcitem.jd.hk/100218556103.html

1.在 visa 的小程序[v 享臻选]中去绑定后边用来消费的 visa 卡并领取 3 美元的返现券
2.再 Apple Pay 绑定这张 visa 卡,然后去消费,我是去充了美区礼品卡,充 10 刀,分两次分别返现了 3 刀和 2 刀,我也不知道这个 2 刀哪里来的-。-
妥妥白捡 5 刀还是香

面试造火箭,进去拧螺丝,很多时候面试题很复杂,脱离实际生产环境,如果是线上面试,有没有哪个 AI 可以分析面试官音视频,生成文字版推荐答案,不用面试者手动输入?仅限于那种范式的面试场景

本周AI行业迎来密集爆发,大模型开源与技术突破并行,百度文心登顶国际榜单,智谱、美团、阶跃星辰等也纷纷发布或开源高性能新模型;AI工具聚焦场景落地,OpenAI与Google掀起翻译工具对决,腾讯混元3D、蚂蚁百灵Ling Studio、阿里呜哩、飞书AI录音豆等深耕垂直场景,实用型显著增强;Agent发展进入新阶段,字节扣子2.0、MiniMax Agent 2.0等升级专业化能力;市场层面基础设施与生态开放成为关键变量,马斯克开放𝕏平台推荐算法并投用GW级超算集群,一起来回顾本周发生的AI新鲜事儿吧!

AI 大模型

百度文心大模型「ERNIE-5.0-0110」登LMArena文本榜国内第一、全球第八

1月15日,百度正式上线的新一代文心大模型「ERNIE-5.0-0110」,在LMArena大模型竞技场以1460分位列文本榜国内第一、全球第八,是该榜单中唯一进入全球前十的中国大模型,数学能力排名全球第二。该模型参数量达2.4万亿,采用原生全模态统一建模技术,支持文本、图像等多种信息的输入与输出,此前Preview版本已拿下LMArena文本榜全球并列第二、国内第一及视觉理解榜国内第一的成绩。

美团LongCat团队开源升级版模型「LongCat-Flash-Thinking-2601」

1月16日,美团LongCat团队发布并开源升级版模型「LongCat-Flash-Thinking-2601」,引入「重思考模式」,在Agentic Search(智能体搜索)、Agentic Tool Use(智能体工具调用)、TIR(工具交互推理)等核心评测基准均达开源SOTA(AIME-25获满分、τ²-Bench 88.2分),泛化能力超越Claude,依托多环境强化学习(DORA基础设施)与噪声环境稳健训练实现技术突破,目前已在GitHub、Hugging Face等平台开源,支持官网在线体验与API免费调用。

Black Forest Labs开源「FLUX.2」[klein]图像生成模型家族

1月17日消息,Black Forest Labs开源「FLUX.2」[klein]图像模型家族,包含4B和9B两个版本(各含未蒸馏的基础版与4步蒸馏版),采用流模型+Qwen3文本编码器架构,统一文生图、图像编辑及多参考生成功能,实现最快0.5秒亚秒级推理,4B版(Apache 2.0许可证支持商用)仅需13GB显存适配消费级GPU,9B版(非商用许可证)性能比肩5倍参数量模型,同步提供FP8/NVFP4量化版本(分别提速1.6倍/2.7倍、显存降低40%/55%),附带推理脚本,兼顾实时应用、微调研究与边缘部署需求。

智谱正式发布并开源混合思考模型「GLM-4.7-Flash」

1月20日,智谱正式发布并开源混合思考模型「GLM-4.7-Flash」,总参数量30B、激活参数量3B,作为同级别SOTA模型兼顾性能与效率,在SWE-bench Verified等主流基准测试中表现超「GPT-OSS-20B」等模型,适配编程、中文写作等多场景,即日起在智谱开放平台上线并免费调用,将替代「GLM-4.5-Flash」(后者1月30日下线),同时可通过Hugging Face、魔搭社区进行开源部署。

阶跃星辰开源10B参数量视觉语言模型「Step3-VL-10B」

1月20日,阶跃星辰开源10B参数量视觉语言模型「Step3-VL-10B」,凭借全参数端到端多模态联合预训练、大规模RL迭代及PaCoRe并行协调推理机制,在视觉感知、逻辑推理、数学竞赛等多维度达到同规模SOTA水平,媲美甚至超越10-20倍参数量的开源与闭源旗舰模型,可下沉至端侧设备运行,目前Base和Thinking版本已通过多个平台开源。

Liquid AI开源非Transformer架构的端侧推理模型「LFM2.5-1.2B-Thinking」

1月21日,由MIT CSAIL孵化的初创公司Liquid AI发布并开源非Transformer架构的端侧推理模型「LFM2.5-1.2B-Thinking」,该模型基于液态神经网络打造,仅需900MB内存即可在手机等设备离线运行,不仅推理速度和质量在同规模模型中领先,参数量比「Qwen3-1.7B」少约40%,却在数学推理、指令遵循、工具使用等核心能力上表现相当或更优,还通过Midtraining、SFT、DPO、RLVR等训练策略将死循环生成比例从15.74%降至0.36%,兼容llama.cpp、MLX等主流推理框架及多品牌硬件,证明Transformer并非唯一解。

中佛罗里达大学发布首个“纯文本提示”医学全能分割模型「Medical SAM3」

1月21日消息,中佛罗里达大学等机构联合发布了首个真正“纯文本提示”驱动的医学全能分割模型「Medical SAM3」,采用全参数微调结合分层学习率衰减策略,依托覆盖10种成像模态、33个数据集的大规模训练底座及统一2D高分辨率视角设计,摆脱了传统医学分割模型对人工边界框等空间提示的依赖,仅凭文本指令即可在CT、MRI、内镜等多模态医学影像中实现专家级分割,内部验证平均Dice从54.0%提升至77.0%,外部零样本场景从11.9%暴涨至73.9%,大幅降低临床交互成本,未来将扩充数据并打造集成LLM的Agent。

百川智能发布循证增强医疗大模型「Baichuan-M3 Plus」

1月22日,百川智能发布循证增强医疗大模型「Baichuan-M3 Plus」,其融合独创六源循证技术与M3基座,将幻觉率降至2.6%达全球最低,首创“证据锚定”技术使医学结论可逐句溯源(匹配准确率超95%),API调用成本较上一代降低70%且限时15天免费体验,同时发起“海纳百川”计划,向中国医疗服务机构免费开放API,用于临床辅助决策与医学教育,推动AI医疗生态发展。

Runway发布全新图生视频模型「Gen 4.5」

1月22日,Runway发布全新图生视频模型「Gen 4.5」,该模型在长故事表达、精准镜头控制、连贯叙事及角色一致性上实现升级,生成视频细节逼真,在1000人盲测中仅57.1%的人能区分其与真实视频。当前视频模型行业呈现真实度与物理一致性增强、声画同步提升等趋势,正逐步接近商业化应用。

AI 工具

AI翻译对决,OpenAI上线「ChatGPT Translate」,Google开源「TranslateGemma」

1月16日消息,OpenAI近期低调上线独立翻译工具「ChatGPT Translate」,支持超50种语言,无需登录即可免费使用,核心亮点是具备译文语气调整等二次加工能力,但暂不支持文档、图片翻译及离线使用。对此Google则高调回应,发布基于Gemma 3的开源翻译模型「TranslateGemma」,提供4B、12B、27B三种参数版本,支持55种语言及多模态输入,12B模型性能超越27B基线模型,4B模型适配移动端/边缘设备,通过双阶段微调流程蒸馏Gemini模型知识,双方竞争推动AI翻译从单纯语言转换向智能适应方向演进。

腾讯「混元3D Studio 1.2」发布公测,组件能力升级至PartGen 1.5

1月16日,腾讯「混元3D Studio 1.2」全新发布并开放公测(无需申请),组件能力升级至PartGen 1.5(拆分精度从1024³提升至1536³分辨率,支持笔刷交互与分割掩码控制,保留高精细节、拆分更完整),基模同步升级为「混元3D 3.1」(几何细节与纹理还原度优化,适配更多风格),新增八视图输入(含顶、底及左右45度视角)提升专业可控性,用户可通过官方链接体验。

蚂蚁集团正式上线百灵大模型官方交互平台「Ling Studio」

1月16日,蚂蚁集团正式上线百灵大模型官方交互平台「Ling Studio」,用户可体验Ling-1T(高速响应)、Ring-1T(复杂推理)、Ming-flash-omni-Preview(多模态识别)等百灵大模型,平台支持调参、系统提示词配置、联网搜索等原生工具调用及API即接即用功能,每日发放50万个免费Tokens,文件对话、图片生成等更多功能即将上线。

阿里巴巴通义千问团队推出一站式AIGC创意生产力平台「呜哩」

1月19日,阿里巴巴通义千问团队推出一站式AIGC创意生产力平台「呜哩」(目前处于测试阶段),该平台集成通义Qwen Image系列、万相2.6等自研模型,以及字节Seedream 4.0/4.5、可灵相关第三方模型,支持文生图、图生图、参考生图、文生视频、图生视频等全功能,生图最高可达4K、生视频最高1080p且支持音画同步,生成速度快(图片几秒、视频1-2分钟),参考生图功能可灵活改图,目前所有功能免费无次数限制,手机号登录即可使用,正式上线后可能收费。

飞书与安克创新联合推出仅重10g的「AI录音豆」,录音整理全自动化

1月20日,飞书与安克创新联合推出「AI录音豆」,这款直径23.2毫米、重10g的微型硬件支持磁吸佩戴,续航达8小时,一键即可录音,录音内容可无缝联动飞书生态,自动生成逐字稿、多语言翻译、会议总结、待办事项等,还能通过飞书知识问答、定时任务、日报周报生成等功能二次加工,解决了手机录音续航、操作繁琐等痛点,将线下录音转化为可协作复用的数字资产,优化了线下会议等场景的录音与内容整理体验。

红杉中国xbench发布「AgentIF-OneDay」评测体系

1月21日,红杉中国xbench发布「AgentIF-OneDay」评测体系,聚焦评估Agent在长时复杂任务中的能力,以人类一天可完成的任务复杂度为基准,涵盖工作流执行、范例参考、迭代式编辑三类场景,包含104道任务及767个细粒度评分点,评测显示Manus、Genspark、ChatGPT-Agent构成第一梯队且各有场景侧重,当前Agent在隐式指令推断等方面仍存短板,未来将推进OneWeek评测,同时持续学习与数据飞轮被认为是Agent向高可靠“数字员工”演进的关键。

AI Agent

超参数科技发布LLM驱动的Game Agent「COTA」,推理链路全程可见

1月16日,超参数科技发布自研Game Agent「COTA」,这是首个以LLM(基座模型Qwen3-VL-8B-Thinking)为核心驱动、具备思维可解释性的游戏智能体,通过“双系统分层架构”(上层指挥官负责战略规划、下层行动专员执行微操)及SFT+GRPO+DPO训练流程,攻克实时响应难题(百毫秒级),在自研FPS游戏环境中展现出接近真人高分玩家的竞技水平,可完成单兵作战与团队战术配合,既降低高拟真NPC开发调试门槛,又能优化玩家体验,其底层技术还具备跨场景迁移潜力,目前已开启官网预约体验。

字节跳动「扣子空间」正式升级为「扣子2.0」,四大Agent能力升级

1月19日,字节跳动拥有千万用户的「扣子空间」升级为「扣子2.0」,核心新增Agent Skills(封装场景最佳实践与工具,支持通过技能商店创建、获取行业专属技能)、Agent Plan(设定长期目标后自动规划执行并主动汇报)、Agent Office(深度理解职场场景,提供针对性洞察与文档处理能力)、Agent Coding(一站式云端开发平台,支持一键部署)四大能力,还上线了音画同步的官方视频创作Skill,定位职场人靠谱伙伴,助力高效完成简历筛选、文案创作、数据报表等各类工作任务。

阶跃星辰正式推出「阶跃AI桌面伙伴Windows版」

1月19日,阶跃星辰正式推出「阶跃AI桌面伙伴Windows版」,同时带来重要升级,该终端Agent定位“会做事、总在场、有记忆、能进化”,此前已发布Mac版(支持日程分析、当前窗口识别等专属功能),现支持调用16款第三方工具且可自行添加,具备本地存储的全局记忆(自动整理电脑活动轨迹并生成复盘报告),用户可通过官网下载。

昆仑万维在Skywork平台推出面向非设计人士的「Skywork Design Agent」

1月19日,昆仑万维在Skywork平台推出面向非设计人士的「Skywork Design Agent」,聚焦海报设计、社媒物料、LOGO与品牌视觉、通用创意生图四大核心场景,通过场景化指引、多启动方式(文生图/以图生图等)、自研画布引擎实现全流程设计,具备AI修图(拆分图层、扩图等)、素材知识库存档、多格式导出等功能,零门槛操作且效果可控,重塑办公视觉创作效率,后续将持续迭代专业功能并拓展AI多媒体创作能力。

MiniMax发布第二代智能体「MiniMax Agent 2.0」,定位“AI原生工作台"

1月20日,MiniMax稀宇科技发布第二代智能体「MiniMax Agent 2.0」,以“AI原生工作台”为核心定位,搭载桌面端应用(双系统适配,打通本地云端无缝衔接)与Expert Agents(定制化专家分身),可高效完成新闻摘要、论文解读、PPT制作等复杂任务,依托Lightning Attention等技术升级及内部迭代闭环,颠覆交互逻辑、打破专业壁垒,重塑AI高复杂度工作价值。

Anthropic被曝升级Claude Cowork,新增「知识库」功能实现“永久记忆”

1月20日消息,Anthropic被曝正在为Claude Cowork进行重大更新,通过新增「知识库」(Knowledge Bases)功能实现“永久记忆”,支持多对话、多任务间持续调用过往关键信息并动态更新,界面简化后新增Artifacts版块管理复用过往作品,同时扩展MCP连接器提升自动化能力,同步优化Web语音模式、Pixelate等轻量化功能,推动其从聊天助手向全面生产力助手演进,而开发者社区也通过Smart Forking等探索印证AI长期记忆的应用价值。

市场动态

Roboparty全栈开源双足人形机器人「萝博头原型机」

1月15日,Roboparty全栈开源双足人形机器人「萝博头原型机」,该原型机身高1.25m、重30kg,跑步速度达3m/s,同步开放硬件结构图、EBOM清单、AMP运控算法及避坑知识库,实现“可复现、可二开、可验证”,其搭载的拟人步态算法适配BFM框架,硬件采用类车规级结构,已获小米战投、商汤等机构千万美元种子轮融资,同时推出开发者共创计划。

马斯克旗下xAI的全球首个GW级超算集群「Colossus 2」正式投入运行

1月17日,马斯克旗下xAI的全球首个GW级超算集群「Colossus 2」正式投入运行,其搭载55.5万张GPU,4月将升级至1.5GW、最终达2GW,专为Grok模型训练服务(Grok 5参数预计6万亿),该集群从建设到上线仅用不到一年(前一代Colossus 1耗时122天);而美国PJM电网因数据中心电力需求激增(未来10年年均增长4.8%),计划在极端天气对13州6700万居民轮流停电,不过「Colossus 2」不在该电网覆盖范围,且xAI部署了特斯拉Megapack储能系统以减少本地电网冲击。

马斯克宣布开源「𝕏平台」推荐算法,每周四迭代一次

1月20日,马斯克宣布开源「𝕏平台」(原Twitter)推荐算法代码,使其成为首个核心流量分发逻辑全透明化的主流社交平台,新版算法采用xAI Grok模型的Transformer架构,以“零人工特征工程”为核心,通过内部“Thunder”和外部“Phoenix Retrieval”召回内容,经Phoenix评分器加权计算得分,评分前后设过滤机制并保障作者多样性,未来将每四周更新开源版本并附开发者说明,这一透明化举措是其他社交平台未做到的。

本周AI行业迎来密集爆发,大模型开源与技术突破并行,百度文心登顶国际榜单,智谱、美团、阶跃星辰等也纷纷发布或开源高性能新模型;AI工具聚焦场景落地,OpenAI与Google掀起翻译工具对决,腾讯混元3D、蚂蚁百灵Ling Studio、阿里呜哩、飞书AI录音豆等深耕垂直场景,实用型显著增强;Agent发展进入新阶段,字节扣子2.0、MiniMax Agent 2.0等升级专业化能力;市场层面基础设施与生态开放成为关键变量,马斯克开放𝕏平台推荐算法并投用GW级超算集群,一起来回顾本周发生的AI新鲜事儿吧!

AI 大模型

百度文心大模型「ERNIE-5.0-0110」登LMArena文本榜国内第一、全球第八

1月15日,百度正式上线的新一代文心大模型「ERNIE-5.0-0110」,在LMArena大模型竞技场以1460分位列文本榜国内第一、全球第八,是该榜单中唯一进入全球前十的中国大模型,数学能力排名全球第二。该模型参数量达2.4万亿,采用原生全模态统一建模技术,支持文本、图像等多种信息的输入与输出,此前Preview版本已拿下LMArena文本榜全球并列第二、国内第一及视觉理解榜国内第一的成绩。

美团LongCat团队开源升级版模型「LongCat-Flash-Thinking-2601」

1月16日,美团LongCat团队发布并开源升级版模型「LongCat-Flash-Thinking-2601」,引入「重思考模式」,在Agentic Search(智能体搜索)、Agentic Tool Use(智能体工具调用)、TIR(工具交互推理)等核心评测基准均达开源SOTA(AIME-25获满分、τ²-Bench 88.2分),泛化能力超越Claude,依托多环境强化学习(DORA基础设施)与噪声环境稳健训练实现技术突破,目前已在GitHub、Hugging Face等平台开源,支持官网在线体验与API免费调用。

Black Forest Labs开源「FLUX.2」[klein]图像生成模型家族

1月17日消息,Black Forest Labs开源「FLUX.2」[klein]图像模型家族,包含4B和9B两个版本(各含未蒸馏的基础版与4步蒸馏版),采用流模型+Qwen3文本编码器架构,统一文生图、图像编辑及多参考生成功能,实现最快0.5秒亚秒级推理,4B版(Apache 2.0许可证支持商用)仅需13GB显存适配消费级GPU,9B版(非商用许可证)性能比肩5倍参数量模型,同步提供FP8/NVFP4量化版本(分别提速1.6倍/2.7倍、显存降低40%/55%),附带推理脚本,兼顾实时应用、微调研究与边缘部署需求。

智谱正式发布并开源混合思考模型「GLM-4.7-Flash」

1月20日,智谱正式发布并开源混合思考模型「GLM-4.7-Flash」,总参数量30B、激活参数量3B,作为同级别SOTA模型兼顾性能与效率,在SWE-bench Verified等主流基准测试中表现超「GPT-OSS-20B」等模型,适配编程、中文写作等多场景,即日起在智谱开放平台上线并免费调用,将替代「GLM-4.5-Flash」(后者1月30日下线),同时可通过Hugging Face、魔搭社区进行开源部署。

阶跃星辰开源10B参数量视觉语言模型「Step3-VL-10B」

1月20日,阶跃星辰开源10B参数量视觉语言模型「Step3-VL-10B」,凭借全参数端到端多模态联合预训练、大规模RL迭代及PaCoRe并行协调推理机制,在视觉感知、逻辑推理、数学竞赛等多维度达到同规模SOTA水平,媲美甚至超越10-20倍参数量的开源与闭源旗舰模型,可下沉至端侧设备运行,目前Base和Thinking版本已通过多个平台开源。

Liquid AI开源非Transformer架构的端侧推理模型「LFM2.5-1.2B-Thinking」

1月21日,由MIT CSAIL孵化的初创公司Liquid AI发布并开源非Transformer架构的端侧推理模型「LFM2.5-1.2B-Thinking」,该模型基于液态神经网络打造,仅需900MB内存即可在手机等设备离线运行,不仅推理速度和质量在同规模模型中领先,参数量比「Qwen3-1.7B」少约40%,却在数学推理、指令遵循、工具使用等核心能力上表现相当或更优,还通过Midtraining、SFT、DPO、RLVR等训练策略将死循环生成比例从15.74%降至0.36%,兼容llama.cpp、MLX等主流推理框架及多品牌硬件,证明Transformer并非唯一解。

中佛罗里达大学发布首个“纯文本提示”医学全能分割模型「Medical SAM3」

1月21日消息,中佛罗里达大学等机构联合发布了首个真正“纯文本提示”驱动的医学全能分割模型「Medical SAM3」,采用全参数微调结合分层学习率衰减策略,依托覆盖10种成像模态、33个数据集的大规模训练底座及统一2D高分辨率视角设计,摆脱了传统医学分割模型对人工边界框等空间提示的依赖,仅凭文本指令即可在CT、MRI、内镜等多模态医学影像中实现专家级分割,内部验证平均Dice从54.0%提升至77.0%,外部零样本场景从11.9%暴涨至73.9%,大幅降低临床交互成本,未来将扩充数据并打造集成LLM的Agent。

百川智能发布循证增强医疗大模型「Baichuan-M3 Plus」

1月22日,百川智能发布循证增强医疗大模型「Baichuan-M3 Plus」,其融合独创六源循证技术与M3基座,将幻觉率降至2.6%达全球最低,首创“证据锚定”技术使医学结论可逐句溯源(匹配准确率超95%),API调用成本较上一代降低70%且限时15天免费体验,同时发起“海纳百川”计划,向中国医疗服务机构免费开放API,用于临床辅助决策与医学教育,推动AI医疗生态发展。

Runway发布全新图生视频模型「Gen 4.5」

1月22日,Runway发布全新图生视频模型「Gen 4.5」,该模型在长故事表达、精准镜头控制、连贯叙事及角色一致性上实现升级,生成视频细节逼真,在1000人盲测中仅57.1%的人能区分其与真实视频。当前视频模型行业呈现真实度与物理一致性增强、声画同步提升等趋势,正逐步接近商业化应用。

AI 工具

AI翻译对决,OpenAI上线「ChatGPT Translate」,Google开源「TranslateGemma」

1月16日消息,OpenAI近期低调上线独立翻译工具「ChatGPT Translate」,支持超50种语言,无需登录即可免费使用,核心亮点是具备译文语气调整等二次加工能力,但暂不支持文档、图片翻译及离线使用。对此Google则高调回应,发布基于Gemma 3的开源翻译模型「TranslateGemma」,提供4B、12B、27B三种参数版本,支持55种语言及多模态输入,12B模型性能超越27B基线模型,4B模型适配移动端/边缘设备,通过双阶段微调流程蒸馏Gemini模型知识,双方竞争推动AI翻译从单纯语言转换向智能适应方向演进。

腾讯「混元3D Studio 1.2」发布公测,组件能力升级至PartGen 1.5

1月16日,腾讯「混元3D Studio 1.2」全新发布并开放公测(无需申请),组件能力升级至PartGen 1.5(拆分精度从1024³提升至1536³分辨率,支持笔刷交互与分割掩码控制,保留高精细节、拆分更完整),基模同步升级为「混元3D 3.1」(几何细节与纹理还原度优化,适配更多风格),新增八视图输入(含顶、底及左右45度视角)提升专业可控性,用户可通过官方链接体验。

蚂蚁集团正式上线百灵大模型官方交互平台「Ling Studio」

1月16日,蚂蚁集团正式上线百灵大模型官方交互平台「Ling Studio」,用户可体验Ling-1T(高速响应)、Ring-1T(复杂推理)、Ming-flash-omni-Preview(多模态识别)等百灵大模型,平台支持调参、系统提示词配置、联网搜索等原生工具调用及API即接即用功能,每日发放50万个免费Tokens,文件对话、图片生成等更多功能即将上线。

阿里巴巴通义千问团队推出一站式AIGC创意生产力平台「呜哩」

1月19日,阿里巴巴通义千问团队推出一站式AIGC创意生产力平台「呜哩」(目前处于测试阶段),该平台集成通义Qwen Image系列、万相2.6等自研模型,以及字节Seedream 4.0/4.5、可灵相关第三方模型,支持文生图、图生图、参考生图、文生视频、图生视频等全功能,生图最高可达4K、生视频最高1080p且支持音画同步,生成速度快(图片几秒、视频1-2分钟),参考生图功能可灵活改图,目前所有功能免费无次数限制,手机号登录即可使用,正式上线后可能收费。

飞书与安克创新联合推出仅重10g的「AI录音豆」,录音整理全自动化

1月20日,飞书与安克创新联合推出「AI录音豆」,这款直径23.2毫米、重10g的微型硬件支持磁吸佩戴,续航达8小时,一键即可录音,录音内容可无缝联动飞书生态,自动生成逐字稿、多语言翻译、会议总结、待办事项等,还能通过飞书知识问答、定时任务、日报周报生成等功能二次加工,解决了手机录音续航、操作繁琐等痛点,将线下录音转化为可协作复用的数字资产,优化了线下会议等场景的录音与内容整理体验。

红杉中国xbench发布「AgentIF-OneDay」评测体系

1月21日,红杉中国xbench发布「AgentIF-OneDay」评测体系,聚焦评估Agent在长时复杂任务中的能力,以人类一天可完成的任务复杂度为基准,涵盖工作流执行、范例参考、迭代式编辑三类场景,包含104道任务及767个细粒度评分点,评测显示Manus、Genspark、ChatGPT-Agent构成第一梯队且各有场景侧重,当前Agent在隐式指令推断等方面仍存短板,未来将推进OneWeek评测,同时持续学习与数据飞轮被认为是Agent向高可靠“数字员工”演进的关键。

AI Agent

超参数科技发布LLM驱动的Game Agent「COTA」,推理链路全程可见

1月16日,超参数科技发布自研Game Agent「COTA」,这是首个以LLM(基座模型Qwen3-VL-8B-Thinking)为核心驱动、具备思维可解释性的游戏智能体,通过“双系统分层架构”(上层指挥官负责战略规划、下层行动专员执行微操)及SFT+GRPO+DPO训练流程,攻克实时响应难题(百毫秒级),在自研FPS游戏环境中展现出接近真人高分玩家的竞技水平,可完成单兵作战与团队战术配合,既降低高拟真NPC开发调试门槛,又能优化玩家体验,其底层技术还具备跨场景迁移潜力,目前已开启官网预约体验。

字节跳动「扣子空间」正式升级为「扣子2.0」,四大Agent能力升级

1月19日,字节跳动拥有千万用户的「扣子空间」升级为「扣子2.0」,核心新增Agent Skills(封装场景最佳实践与工具,支持通过技能商店创建、获取行业专属技能)、Agent Plan(设定长期目标后自动规划执行并主动汇报)、Agent Office(深度理解职场场景,提供针对性洞察与文档处理能力)、Agent Coding(一站式云端开发平台,支持一键部署)四大能力,还上线了音画同步的官方视频创作Skill,定位职场人靠谱伙伴,助力高效完成简历筛选、文案创作、数据报表等各类工作任务。

阶跃星辰正式推出「阶跃AI桌面伙伴Windows版」

1月19日,阶跃星辰正式推出「阶跃AI桌面伙伴Windows版」,同时带来重要升级,该终端Agent定位“会做事、总在场、有记忆、能进化”,此前已发布Mac版(支持日程分析、当前窗口识别等专属功能),现支持调用16款第三方工具且可自行添加,具备本地存储的全局记忆(自动整理电脑活动轨迹并生成复盘报告),用户可通过官网下载。

昆仑万维在Skywork平台推出面向非设计人士的「Skywork Design Agent」

1月19日,昆仑万维在Skywork平台推出面向非设计人士的「Skywork Design Agent」,聚焦海报设计、社媒物料、LOGO与品牌视觉、通用创意生图四大核心场景,通过场景化指引、多启动方式(文生图/以图生图等)、自研画布引擎实现全流程设计,具备AI修图(拆分图层、扩图等)、素材知识库存档、多格式导出等功能,零门槛操作且效果可控,重塑办公视觉创作效率,后续将持续迭代专业功能并拓展AI多媒体创作能力。

MiniMax发布第二代智能体「MiniMax Agent 2.0」,定位“AI原生工作台"

1月20日,MiniMax稀宇科技发布第二代智能体「MiniMax Agent 2.0」,以“AI原生工作台”为核心定位,搭载桌面端应用(双系统适配,打通本地云端无缝衔接)与Expert Agents(定制化专家分身),可高效完成新闻摘要、论文解读、PPT制作等复杂任务,依托Lightning Attention等技术升级及内部迭代闭环,颠覆交互逻辑、打破专业壁垒,重塑AI高复杂度工作价值。

Anthropic被曝升级Claude Cowork,新增「知识库」功能实现“永久记忆”

1月20日消息,Anthropic被曝正在为Claude Cowork进行重大更新,通过新增「知识库」(Knowledge Bases)功能实现“永久记忆”,支持多对话、多任务间持续调用过往关键信息并动态更新,界面简化后新增Artifacts版块管理复用过往作品,同时扩展MCP连接器提升自动化能力,同步优化Web语音模式、Pixelate等轻量化功能,推动其从聊天助手向全面生产力助手演进,而开发者社区也通过Smart Forking等探索印证AI长期记忆的应用价值。

市场动态

Roboparty全栈开源双足人形机器人「萝博头原型机」

1月15日,Roboparty全栈开源双足人形机器人「萝博头原型机」,该原型机身高1.25m、重30kg,跑步速度达3m/s,同步开放硬件结构图、EBOM清单、AMP运控算法及避坑知识库,实现“可复现、可二开、可验证”,其搭载的拟人步态算法适配BFM框架,硬件采用类车规级结构,已获小米战投、商汤等机构千万美元种子轮融资,同时推出开发者共创计划。

马斯克旗下xAI的全球首个GW级超算集群「Colossus 2」正式投入运行

1月17日,马斯克旗下xAI的全球首个GW级超算集群「Colossus 2」正式投入运行,其搭载55.5万张GPU,4月将升级至1.5GW、最终达2GW,专为Grok模型训练服务(Grok 5参数预计6万亿),该集群从建设到上线仅用不到一年(前一代Colossus 1耗时122天);而美国PJM电网因数据中心电力需求激增(未来10年年均增长4.8%),计划在极端天气对13州6700万居民轮流停电,不过「Colossus 2」不在该电网覆盖范围,且xAI部署了特斯拉Megapack储能系统以减少本地电网冲击。

马斯克宣布开源「𝕏平台」推荐算法,每周四迭代一次

1月20日,马斯克宣布开源「𝕏平台」(原Twitter)推荐算法代码,使其成为首个核心流量分发逻辑全透明化的主流社交平台,新版算法采用xAI Grok模型的Transformer架构,以“零人工特征工程”为核心,通过内部“Thunder”和外部“Phoenix Retrieval”召回内容,经Phoenix评分器加权计算得分,评分前后设过滤机制并保障作者多样性,未来将每四周更新开源版本并附开发者说明,这一透明化举措是其他社交平台未做到的。

你好,我是 Silvana,一名前端开发工程师菜鸟。

介绍:

最近琢磨出一个简单又有特色的 CSS 小效果 —— 倒边框半径的卡片,用来做个人名片类的展示特别合适,不用复杂的插件,纯 HTML+CSS 就能实现,分享给喜欢折腾前端小效果的朋友~

这个卡片的核心是用 CSS 伪元素搭配阴影模拟出 “倒圆角” 的视觉效果,整体结构不复杂,下面把完整的代码和详细注释贴出来,新手也能轻松看懂、直接套用~

完整源码(附详细注释)

1. HTML 部分(index.html)

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <!-- 适配移动端视图 -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>CSS 倒边框半径卡</title>
    <!-- 引入样式文件 -->
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <!-- 卡片容器 -->
    <div class="card">
      <!-- 顶部卡片区域(放视频背景) -->
      <div class="box">
        <div class="imgBx">
          <!-- 自动循环播放且静音的视频背景 -->
          <video src="cover.mp4" type="video/mp4" autoplay loop muted></video>
        </div>
      </div>
      <!-- 底部卡片区域(放个人信息) -->
      <div class="box">
        <div class="content">
          <!-- 姓名和身份 -->
          <h2>Lila Simmons<br/><span>Professional Artist</span></h2>
          <!-- 数据统计 -->
          <ul>
            <li>Posts<span>62</span></li>
            <li>Followers<span>120</span></li>
            <li>Following<span>47</span></li>
          </ul>
          <!-- 关注按钮 -->
          <button>Follower</button>
        </div>
      </div>
      <!-- 左侧圆形头像区域 -->
      <div class="circle">
        <div class="imgBx">
          <img src="user.png" alt="用户头像">
        </div>
      </div>
    </div>
  </body>
</html>

2. CSS 部分(style.css)

/* 全局样式重置 */
* {
  margin: 0;
  padding: 0;
  /* 盒模型:宽高包含边框和内边距 */
  box-sizing: border-box;
}
/* 定义全局颜色变量,方便统一修改 */
:root {
  --clr: #083d41
}
/* 页面整体样式:居中展示,背景色用变量 */
body{
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
  background: var(--clr);
}
/* 卡片容器:相对定位,设置宽高,纵向排列子元素 */
.card {
  position: relative;
  width: 320px;
  height: 430px;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}
/* 卡片内的两个box通用样式 */
.card .box {
  position: relative;
  width: 110%;
  height: 200px;
  border-radius: 15px;
}
/* 第一个box(视频区域):伪元素做左侧倒圆角 */
.card .box:nth-child(1) {
  background: #f00; /* 视频区域背景(被视频覆盖) */
}
.card .box:nth-child(1)::before {
  content: "";
  position: absolute;
  top: 106px;
  left: -1px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-bottom-left-radius: 20px;
  /* 利用阴影模拟倒圆角效果,颜色和页面背景一致 */
  box-shadow: -6px 6px var(--clr);
}
/* 第一个box:伪元素做底部倒圆角 */
.card .box:nth-child(1)::after {
  content: "";
  position: absolute;
  bottom: -1px;
  left: 105px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-bottom-left-radius: 20px;
  box-shadow: -6px 6px var(--clr);
}
/* 第二个box(信息区域):调整宽高和背景色 */
.card .box:nth-child(2) {
  background: #fff;
  height: 220px;
  width: 100%;
}
/* 第二个box:伪元素做左侧倒圆角 */
.card .box:nth-child(2)::before {
  content: "";
  position: absolute;
  bottom: 106px;
  left: -1px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-top-left-radius: 20px;
  box-shadow: -6px -6px var(--clr);
}
/* 第二个box:伪元素做顶部倒圆角 */
.card .box:nth-child(2)::after {
  content: "";
  position: absolute;
  top: -1px;
  left: 109px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-top-left-radius: 20px;
  box-shadow: -6px -6px var(--clr);
}
/* 左侧圆形头像容器:绝对定位,居中显示 */
.card .circle {
  position: absolute;
  top: 50%;
  left: -70px;
  transform: translateY(-50%);
  width: 180px;
  height: 180px;
  border-radius: 50%;
  /* 边框颜色和页面背景一致,营造镂空感 */
  border: 10px solid var(--clr);
}
/* 头像和视频容器通用样式:溢出隐藏,适配圆角 */
.card .circle .imgBx,
.card .box .imgBx {
  position: absolute;
  inset: 0;
  overflow: hidden;
  border-radius: 50%;
}
/* 视频容器单独调整圆角,适配卡片 */
.card .box .imgBx {
  border-radius: 15px;
}
/* 头像和视频内容:铺满容器,保持比例 */
.card .circle .imgBx img,
.card .box .imgBx video {
  position: absolute;
  width: 100%;
  height: 100%;
  object-fit: cover;
}
/* 信息区域布局:居中排列,内边距调整 */
.card .box .content{
  position: absolute;
  inset: 0;
  padding: 30px 10px 20px;
  display: flex;
  align-items: center;
  flex-direction: column;
  gap: 20px;
}
/* 姓名样式:排版调整,颜色区分 */
.card .box .content h2{
  width: 100%;
  padding-left: 120px;
  text-transform: uppercase;
  font-size: 1.15em;
  letter-spacing: 0.1em;
  font-weight: 600;
  line-height: 1.1em;
  color: #333;
}
/* 身份文字:字号和颜色调整 */
.card .box .content h2 span {
  font-size: 0.75em;
  font-weight: 400;
  letter-spacing: 0.05em;
  color: #e91e63;
  text-transform: initial;
}
/* 数据统计列表:网格布局,均分宽度 */
.card .box .content ul {
  position: relative;
  top: 15px;
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  width: 100%;
  padding: 0 10px;
  justify-content: space-evenly;
}
/* 列表项样式:纵向排列,文字颜色区分 */
.card .box .content ul li {
  list-style: none;
  display: flex;
  flex-direction: column;
  text-align: center;
  padding: 0 10px;
  font-size: 0.85em;
  font-weight: 500;
  color: #999;
}
/* 列表项分隔线:除最后一个外,右侧加边框 */
.card .box .content ul li:not(:last-child) {
  border-right: 1px solid #ccc;
}
/* 数据数字:字号放大,颜色加深 */
.card .box .content ul li span {
  font-size: 1.65em;
  color: #333;
}
/* 关注按钮样式:圆角、阴影、边框营造层次感 */
.card .box .content button {
  position: relative;
  top: 25px;
  padding: 8px 30px;
  border: none;
  outline: none;
  background: #03a9f4;
  border-radius: 30px;
  color: #fff;
  font-size: 1em;
  letter-spacing: .2em;
  text-transform: uppercase;
  font-weight: 500;
  cursor: pointer;
  border: 5px solid var(--clr);
  box-shadow: 0 0 0 10px #fff;
  transition: 0.5s;
}
/* 按钮hover效果:文字间距变大,背景色改变 */
.card .box .content button:hover{
  letter-spacing: 0.5em;
  background: #ff3d7f;
}
/* 按钮左侧倒圆角伪元素 */
.card .box .content button::before{
  content: "";
  position: absolute;
  top: 24px;
  left: -29px;
  width: 20px;
  height: 20px;
  background: transparent;
  border-top-right-radius: 20px;
  box-shadow: 5px -7px #fff;
}
/* 按钮右侧倒圆角伪元素 */
.card .box .content button::after{
  content: "";
  position: absolute;
  top: 24px;
  right: -29px;
  width: 20px;
  height: 20px;
  background: transparent;
  border-top-left-radius: 20px;
  box-shadow: -5px -7px #fff;
}

替换里面的cover.mp4和user.png为自己的素材就能直接用,核心的倒圆角效果都在伪元素的box-shadow那里,调整数值还能改倒圆角的大小,感兴趣的可以自己试试。

写着写着就到了结尾,祝您今晚有个好梦(代码少报错一点)。

本文由mdnice多平台发布

你好,我是 Silvana,一名前端开发工程师菜鸟。

介绍:

最近琢磨出一个简单又有特色的 CSS 小效果 —— 倒边框半径的卡片,用来做个人名片类的展示特别合适,不用复杂的插件,纯 HTML+CSS 就能实现,分享给喜欢折腾前端小效果的朋友~

这个卡片的核心是用 CSS 伪元素搭配阴影模拟出 “倒圆角” 的视觉效果,整体结构不复杂,下面把完整的代码和详细注释贴出来,新手也能轻松看懂、直接套用~

完整源码(附详细注释)

1. HTML 部分(index.html)

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <!-- 适配移动端视图 -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>CSS 倒边框半径卡</title>
    <!-- 引入样式文件 -->
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <!-- 卡片容器 -->
    <div class="card">
      <!-- 顶部卡片区域(放视频背景) -->
      <div class="box">
        <div class="imgBx">
          <!-- 自动循环播放且静音的视频背景 -->
          <video src="cover.mp4" type="video/mp4" autoplay loop muted></video>
        </div>
      </div>
      <!-- 底部卡片区域(放个人信息) -->
      <div class="box">
        <div class="content">
          <!-- 姓名和身份 -->
          <h2>Lila Simmons<br/><span>Professional Artist</span></h2>
          <!-- 数据统计 -->
          <ul>
            <li>Posts<span>62</span></li>
            <li>Followers<span>120</span></li>
            <li>Following<span>47</span></li>
          </ul>
          <!-- 关注按钮 -->
          <button>Follower</button>
        </div>
      </div>
      <!-- 左侧圆形头像区域 -->
      <div class="circle">
        <div class="imgBx">
          <img src="user.png" alt="用户头像">
        </div>
      </div>
    </div>
  </body>
</html>

2. CSS 部分(style.css)

/* 全局样式重置 */
* {
  margin: 0;
  padding: 0;
  /* 盒模型:宽高包含边框和内边距 */
  box-sizing: border-box;
}
/* 定义全局颜色变量,方便统一修改 */
:root {
  --clr: #083d41
}
/* 页面整体样式:居中展示,背景色用变量 */
body{
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
  background: var(--clr);
}
/* 卡片容器:相对定位,设置宽高,纵向排列子元素 */
.card {
  position: relative;
  width: 320px;
  height: 430px;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}
/* 卡片内的两个box通用样式 */
.card .box {
  position: relative;
  width: 110%;
  height: 200px;
  border-radius: 15px;
}
/* 第一个box(视频区域):伪元素做左侧倒圆角 */
.card .box:nth-child(1) {
  background: #f00; /* 视频区域背景(被视频覆盖) */
}
.card .box:nth-child(1)::before {
  content: "";
  position: absolute;
  top: 106px;
  left: -1px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-bottom-left-radius: 20px;
  /* 利用阴影模拟倒圆角效果,颜色和页面背景一致 */
  box-shadow: -6px 6px var(--clr);
}
/* 第一个box:伪元素做底部倒圆角 */
.card .box:nth-child(1)::after {
  content: "";
  position: absolute;
  bottom: -1px;
  left: 105px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-bottom-left-radius: 20px;
  box-shadow: -6px 6px var(--clr);
}
/* 第二个box(信息区域):调整宽高和背景色 */
.card .box:nth-child(2) {
  background: #fff;
  height: 220px;
  width: 100%;
}
/* 第二个box:伪元素做左侧倒圆角 */
.card .box:nth-child(2)::before {
  content: "";
  position: absolute;
  bottom: 106px;
  left: -1px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-top-left-radius: 20px;
  box-shadow: -6px -6px var(--clr);
}
/* 第二个box:伪元素做顶部倒圆角 */
.card .box:nth-child(2)::after {
  content: "";
  position: absolute;
  top: -1px;
  left: 109px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-top-left-radius: 20px;
  box-shadow: -6px -6px var(--clr);
}
/* 左侧圆形头像容器:绝对定位,居中显示 */
.card .circle {
  position: absolute;
  top: 50%;
  left: -70px;
  transform: translateY(-50%);
  width: 180px;
  height: 180px;
  border-radius: 50%;
  /* 边框颜色和页面背景一致,营造镂空感 */
  border: 10px solid var(--clr);
}
/* 头像和视频容器通用样式:溢出隐藏,适配圆角 */
.card .circle .imgBx,
.card .box .imgBx {
  position: absolute;
  inset: 0;
  overflow: hidden;
  border-radius: 50%;
}
/* 视频容器单独调整圆角,适配卡片 */
.card .box .imgBx {
  border-radius: 15px;
}
/* 头像和视频内容:铺满容器,保持比例 */
.card .circle .imgBx img,
.card .box .imgBx video {
  position: absolute;
  width: 100%;
  height: 100%;
  object-fit: cover;
}
/* 信息区域布局:居中排列,内边距调整 */
.card .box .content{
  position: absolute;
  inset: 0;
  padding: 30px 10px 20px;
  display: flex;
  align-items: center;
  flex-direction: column;
  gap: 20px;
}
/* 姓名样式:排版调整,颜色区分 */
.card .box .content h2{
  width: 100%;
  padding-left: 120px;
  text-transform: uppercase;
  font-size: 1.15em;
  letter-spacing: 0.1em;
  font-weight: 600;
  line-height: 1.1em;
  color: #333;
}
/* 身份文字:字号和颜色调整 */
.card .box .content h2 span {
  font-size: 0.75em;
  font-weight: 400;
  letter-spacing: 0.05em;
  color: #e91e63;
  text-transform: initial;
}
/* 数据统计列表:网格布局,均分宽度 */
.card .box .content ul {
  position: relative;
  top: 15px;
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  width: 100%;
  padding: 0 10px;
  justify-content: space-evenly;
}
/* 列表项样式:纵向排列,文字颜色区分 */
.card .box .content ul li {
  list-style: none;
  display: flex;
  flex-direction: column;
  text-align: center;
  padding: 0 10px;
  font-size: 0.85em;
  font-weight: 500;
  color: #999;
}
/* 列表项分隔线:除最后一个外,右侧加边框 */
.card .box .content ul li:not(:last-child) {
  border-right: 1px solid #ccc;
}
/* 数据数字:字号放大,颜色加深 */
.card .box .content ul li span {
  font-size: 1.65em;
  color: #333;
}
/* 关注按钮样式:圆角、阴影、边框营造层次感 */
.card .box .content button {
  position: relative;
  top: 25px;
  padding: 8px 30px;
  border: none;
  outline: none;
  background: #03a9f4;
  border-radius: 30px;
  color: #fff;
  font-size: 1em;
  letter-spacing: .2em;
  text-transform: uppercase;
  font-weight: 500;
  cursor: pointer;
  border: 5px solid var(--clr);
  box-shadow: 0 0 0 10px #fff;
  transition: 0.5s;
}
/* 按钮hover效果:文字间距变大,背景色改变 */
.card .box .content button:hover{
  letter-spacing: 0.5em;
  background: #ff3d7f;
}
/* 按钮左侧倒圆角伪元素 */
.card .box .content button::before{
  content: "";
  position: absolute;
  top: 24px;
  left: -29px;
  width: 20px;
  height: 20px;
  background: transparent;
  border-top-right-radius: 20px;
  box-shadow: 5px -7px #fff;
}
/* 按钮右侧倒圆角伪元素 */
.card .box .content button::after{
  content: "";
  position: absolute;
  top: 24px;
  right: -29px;
  width: 20px;
  height: 20px;
  background: transparent;
  border-top-left-radius: 20px;
  box-shadow: -5px -7px #fff;
}

替换里面的cover.mp4和user.png为自己的素材就能直接用,核心的倒圆角效果都在伪元素的box-shadow那里,调整数值还能改倒圆角的大小,感兴趣的可以自己试试。

写着写着就到了结尾,祝您今晚有个好梦(代码少报错一点)。

本文由mdnice多平台发布

分析 Linux/Unix 系统及其他网络设备生成的系统日志(Syslog),是IT管理员的核心工作内容之一。为提升日志分析的效率,管理员通常会采用日志集中采集的方式。本文详细介绍将 CentOS 系统配置为 rsyslog 集中采集服务器的具体步骤。

Rsyslog 服务在 CentOS 8 系统中为默认预装状态。你可在终端执行以下命令,检查服务运行状态:

$ systemctl status rsyslog

若命令返回的服务状态不为 Active: active (running)(运行中),请在终端执行以下命令安装 rsyslog:

$ sudo yum install rsyslog

如需通过 UDP 和 TCP 协议接收来自其他设备的系统日志,需编辑配置文件 /etc/rsyslog.conf,取消对应配置项的注释,以启用 TCP 和 UDP 监听功能。

•启用 UDP 协议:取消以下配置行的注释
module(load="imudp") #needs to be done just once
input(type="imudp" port="514")

•启用 TCP 协议:取消以下配置行的注释
module(load="imtcp") #needs to be done just once
input(type="imtcp" port="514")

注意

514 是 UDP 和 TCP 协议的默认监听端口,你可根据实际需求修改端口号。

保存配置并退出编辑界面。

确保客户端主机能够识别并与已配置的 rsyslog 服务器通信。为开放通信端口,需在防火墙中放行 514 端口,执行以下命令:

$ sudo firewall-cmd --add-port=514/tcp --zone=public --permanent
重新加载防火墙配置,使规则生效:

$ sudo firewall-cmd --reload
重启 rsyslog 服务,并执行以下命令,检查服务器是否已在 514 端口监听:

$ sudo netstat -pnltu
若配置成功,你会看到 514 端口的状态显示为 LISTEN(监听中)。

至此,基于 CentOS 系统的集中式 Syslog 采集服务器已配置完成。如需实时查看已采集的日志,可在服务器端执行以下命令:

$ tail -f /var/log/messages

如何监控 rsyslog 日志文件

监控系统日志文件至关重要,这些日志可直观反映网络活动的详细情况,包括事件涉及的 IP 地址、时间戳、具体操作行为,以及对系统执行的关键配置变更等信息。

但手动监控 rsyslog 日志文件耗时费力,且难以实现高效的日志分析。通过专业的日志管理解决方案监控 rsyslog 日志,能够对日志数据进行深度解析。

EventLog Analyzer 是一款功能完善的日志管理工具,它可实现海量 rsyslog 数据的采集、解析、索引与分析,并生成可视化的统计报告。

工具会自动将检测到的恶意行为标记为安全威胁,并通过短信或邮件触发实时告警,及时通知 IT 安全管理员防范潜在的网络攻击。

分析 Linux/Unix 系统及其他网络设备生成的系统日志(Syslog),是IT管理员的核心工作内容之一。为提升日志分析的效率,管理员通常会采用日志集中采集的方式。本文详细介绍将 CentOS 系统配置为 rsyslog 集中采集服务器的具体步骤。

Rsyslog 服务在 CentOS 8 系统中为默认预装状态。你可在终端执行以下命令,检查服务运行状态:

$ systemctl status rsyslog

若命令返回的服务状态不为 Active: active (running)(运行中),请在终端执行以下命令安装 rsyslog:

$ sudo yum install rsyslog

如需通过 UDP 和 TCP 协议接收来自其他设备的系统日志,需编辑配置文件 /etc/rsyslog.conf,取消对应配置项的注释,以启用 TCP 和 UDP 监听功能。

•启用 UDP 协议:取消以下配置行的注释
module(load="imudp") #needs to be done just once
input(type="imudp" port="514")

•启用 TCP 协议:取消以下配置行的注释
module(load="imtcp") #needs to be done just once
input(type="imtcp" port="514")

注意

514 是 UDP 和 TCP 协议的默认监听端口,你可根据实际需求修改端口号。

保存配置并退出编辑界面。

确保客户端主机能够识别并与已配置的 rsyslog 服务器通信。为开放通信端口,需在防火墙中放行 514 端口,执行以下命令:

$ sudo firewall-cmd --add-port=514/tcp --zone=public --permanent
重新加载防火墙配置,使规则生效:

$ sudo firewall-cmd --reload
重启 rsyslog 服务,并执行以下命令,检查服务器是否已在 514 端口监听:

$ sudo netstat -pnltu
若配置成功,你会看到 514 端口的状态显示为 LISTEN(监听中)。

至此,基于 CentOS 系统的集中式 Syslog 采集服务器已配置完成。如需实时查看已采集的日志,可在服务器端执行以下命令:

$ tail -f /var/log/messages

如何监控 rsyslog 日志文件

监控系统日志文件至关重要,这些日志可直观反映网络活动的详细情况,包括事件涉及的 IP 地址、时间戳、具体操作行为,以及对系统执行的关键配置变更等信息。

但手动监控 rsyslog 日志文件耗时费力,且难以实现高效的日志分析。通过专业的日志管理解决方案监控 rsyslog 日志,能够对日志数据进行深度解析。

EventLog Analyzer 是一款功能完善的日志管理工具,它可实现海量 rsyslog 数据的采集、解析、索引与分析,并生成可视化的统计报告。

工具会自动将检测到的恶意行为标记为安全威胁,并通过短信或邮件触发实时告警,及时通知 IT 安全管理员防范潜在的网络攻击。