Harrison Chase（LangChain 联合创始人兼 CEO）那篇《How Coding Agents Are Reshaping Engineering, Product and Design》中文翻译：

编程Agent如何重塑工程、产品与设计

软件公司的 EPD（工程、产品与设计） 的核心是创建优秀的软件。虽然这些角色是分开的，但最终目标是产出能够解决商业问题、用户可用的功能性软件。归根结底，这一切都是代码。认识到 EPD 的产出本质上就是代码非常重要，因为……编程Agent突然让写代码变得非常容易。那么，这将如何改变 EPD 的角色呢？

流程的改变

1. PRD（产品需求文档）已死
在 Claude 时代之前，PRD 是软件开发的核心。EPD 的流程通常是这样的：

1. 有人（通常是产品经理）有了一个想法
2. 产品经理写一份 PRD
3. 设计师根据 PRD 制作原型图
4. 工程师将原型图转化为代码

想法 → PRD → 原型图 → 代码

这并非硬性规定（在初创公司这些步骤是融合的，最好的构建者能同时做多项工作），但这是教科书式的开发方式。

之所以这样，是因为构建软件（和原型图）需要大量的时间和精力。因此，人们创造了专门的学科来处理这些工作。随着专业化程度提高，跨学科沟通的需求也随之产生。PRD 就是这一切的基础，它启动了整个流程。然后它像瀑布一样流向设计，设计师将漂亮的文字转化为漂亮的 UI 和流畅的 UX。最后工程师将其变为现实。

编程Agent改变了这一切。 编程Agent可以直接将一个想法转化为功能软件。当我说（以及其他人说）“PRD 已死”时，我们真正的意思是：这种从撰写 PRD 开始的传统软件构建方式已经终结了。

2. 瓶颈从“实施”转移到了“评审”
现在任何人都能写代码，这意味着任何人都能构建东西。但这并不意味着构建出来的东西架构良好、解决了正确的问题或者易于使用。工程、产品和设计应该成为这些领域的评审者和仲裁者。

问题是，生成的代码并不总是“优秀”的。EPD 的角色变成了评审并确保它是“优秀的”。“优秀”可以指代几层含义：

• 工程系统视角： 架构是否可扩展、高性能且稳健？
• 产品视角： 这是否解决了用户的痛点？
• 设计视角： 界面是否易于使用且直观？

由于创建初始版本代码的成本极低，我们看到产生了更多的原型。这些原型成为焦点，由产品、工程和设计进行评审。

想法 → 代码 → [产品反馈 / 工程反馈 / 设计反馈]

问题是——生成代码太容易了。以前，创建代码需要很长时间，所以作为评审者，你桌面上待审的项目数量有限。但现在——任何人都能写代码。这意味着正在进行的项目数量在增加。我们发现瓶颈（在所有三个职能中）在于评审——即拿走这些原型并确保它们是“好”的。

3. PRD 万岁
Claude 时代之前的软件构建方式（从 PRD 开始）已经过去。但描述产品需求的文档仍然是必不可少的。

假设有人有一个想法并快速构建了一个原型。如何将其投入生产？它需要经过 EPD 的其他成员评审。在这个过程中，书面文档总是有帮助的，而且往往是必要的。当其他人进行评审时，他们怎么知道代码的某一部分是偶然存在的还是有意为之的？这取决于意图。需要某种形式的意图沟通。

我认为传统的 PRD 流程（PRD → 原型图 → 代码）已经死了。但描述产品需求的文本还活着。这份相关文档应该是原型的必备伴侣，在移交评审之前必须存在。最标准的格式是文档，但也有一些关于共享创建此功能所用提示词（Prompts）的有趣想法。如果未来的 PRD 只是结构化的、版本化的提示词呢？

想法 → 文档 → 代码 → [产品反馈 / 工程反馈 / 设计反馈]

对角色的影响

1. 通才比以往任何时候都更有价值
我说的通才，是指对产品、工程和设计都有良好感知的人。这些人一直都很有价值且有影响力——但在编程Agent时代，他们更是如此。为什么？
沟通是一切中最难的部分。它会拖慢进度。 一个能同时做产品、设计和工程的人，会比一个三人的团队跑得更快，因为没有沟通开销。

以前，当实施是阻碍时，这个通才仍然需要与他人沟通才能完成工作。现在他们只需要与Agent沟通。这意味着他们仅凭自己就能产生比以往任何时候都大得多的影响力。

2. 编程Agent是刚需
随着编程Agent让实施变得廉价，使用它们成为了一种要求。能够采用编程Agent的人将能凭一己之力做更多的事：

• 产品经理： 采用编程Agent可以直接通过构建原型来验证想法，而无需撰写规格说明书和等待。
• 设计师： 采用编程Agent可以在代码中迭代，而不仅仅是在 Figma 中。
• 工程师： 采用编程Agent可以将时间从实施转移到系统思考。

采用编程Agent是刚需，因为这并不难，如果你不这样做，你就会被使用它的人取代。

3. 好的产品经理很棒，糟糕的产品经理很可怕
好的产品思维比以往任何时候都更有价值——你可以构建有用的东西。糟糕的产品思维比以往任何时候都更浪费。如果有人有一个糟糕的产品想法，他们可以带着一个原型出现——但这个原型将是一个无用或构思拙劣的功能。这些原型现在需要更多的评审——来自工程、产品和设计。这消耗了时间和资源。而且，将这些原型投入生产的惯性更大（“它已经存在了！我们就合并它吧！”）。这有制造出更差或臃肿产品的风险。

（此处原文有图表：糟糕的 PM 使用 AI 产生负价值，优秀的 PM 使用 AI 产生高价值）

4. 系统思考是需要磨练的技能
在一个执行廉价的世界里，系统思考成为了差异化因素。你应该专注于擅长系统思考，并对你特定的领域有清晰的心智模型：

• 工程： 对如何架构服务、API 和数据库有极佳的心智模型。
• 产品： 对用户真正需要什么（而不是他们说想要什么）有极佳的心智模型。
• 设计： 对为什么某些东西看起来和用起来感觉对劲有极佳的心智模型。

系统思考一直很重要——那么什么变了？实施成本大幅下降。 这意味着实施某件事比以往任何时候都容易——但这并不意味着它很棒。成为一个好的系统思考者可以让你确保你一开始就构建了正确的东西。它也让你在事后评审他人的工作。这两点都意味着成为好的系统思考者的重要性增加了。

5. 每个人都需要产品感
编程Agent仍然需要有人向它们发出提示。有人告诉它们做什么。如果你告诉它们构建错误的东西——你就是在为其他人制造更多需要评审的垃圾。知道告诉Agent构建什么（“产品感”）是必须的，否则你会成为组织的拖累。这在工程、设计和（显然的）产品中都是如此。

EPD 的很大一部分现在是评审原型。如果你有产品感，评审设计/工程会更容易。如果你没有产品感，你需要一份与原型并行的超级详细的产品文档。如果你有产品感，你只需要最小的规格说明书就能理解功能的意图，从而加速沟通、评审和交付。

6. 专业化的门槛变高了
你需要知道如何使用编程Agent。你需要产品感。所有角色都在融合。

角色之间一直存在重叠。设计和产品长期以来联系紧密——在苹果和 Airbnb 等公司，设计师充当产品经理。“设计工程师”作为一种角色在 Vercel 等公司越来越流行。

这并不意味着没有专业化的空间。一个只思考系统架构的资深工程师仍然很有价值。就像一个没有掌握“氛围编码”（vibe coding）但对客户问题和构建内容有超级清晰心智模型的 PM 一样。设计师也是如此，他们可以理解和模拟用户旅程和交互，即使仍在使用 Figma。

但专业化的门槛更高了。你不仅要精通你的领域，还要在评审上极快，并且是令人难以置信的沟通者。而且在任何给定的公司里，可能都没有那么多这些角色。

7. 你不是构建者，就是评审者
我们在 EPD 中看到了两种不同类型的角色正在出现。

第一：构建者（Builders）。 这种原型具有良好的产品思维，能够使用编程Agent，并具备基础的设计直觉。在一定的限制范围内（测试套件、组件库），他们可以将小型功能从想法推向生产，并为大型功能制作功能原型。

第二：评审者（Reviewers）。 对于大型和复杂的功能，需要详细的 EPD 评审。这对评审者的要求很高——你必须是你领域的杰出系统思考者。你还必须以快节奏工作——有太多东西需要评审。

如果你现在是一名工程师——你应该要么努力在系统设计上变得出色并习惯评审架构，立志成为一名评审者……要么尝试增长你的产品/设计技能并成为一名构建者。

如果你在产品或设计领域——你必须要么对产品/设计有极佳的心智模型并主要进行评审……要么跳进编程Agent并提高你的编码能力。

（此处原文有图表：横轴为工程能力，纵轴为产品/设计思维）

• 独角兽（Unicorns）： 高工程能力 + 高产品/设计思维（构建者）
• 开始有麻烦的人： 低工程能力 + 高产品/设计思维（产品/设计评审者）
• 开始有麻烦的人： 高工程能力 + 低产品/设计思维（工程评审者）
• 总是有麻烦的人： 低工程能力 + 低产品/设计思维

有趣的是，角色正在某种程度上瓦解，如上图所示。角色开始融合——工程师有更多时间，可以更多地思考产品和设计。产品和设计可以创建代码。

8. 每个人都认为他们的角色从编程Agent中获益最大——而且他们是对的
Twitter 上有一篇关于从编程Agent中获益最大的人类型的精彩帖子：

“一个对现有产品有直观把握的人，知道它的软肋在哪里，哪里表现出色，以及如何将其迭代得更加锐利。
这种人的罕见版本存在于文化和深度技术的交界处。一个真正双语的人。他们知道技术上什么是可能的，也知道哪些文化潮流是真实的，哪些是短暂的。这种组合区分了那些感觉不可避免的产品和那些感觉是拼凑起来的产品。”

这篇文章很好地概括了这个新世界，它一度半病毒式传播。它之所以走红，是因为每个读到它的人都认为这是在说他们或他们的角色。我看到产品经理在引用它，设计师、设计工程师、创始人……每个人都认为它适用于他们和他们的角色。

而且他们可能都对！我认为这个新世界最令人兴奋的事情是，背景变得不那么重要了。我真心相信这种原型人物可能来自产品、设计或工程。这并不意味着每个人都会成为这种人——这说起来容易做起来难。真正的独角兽非常少。

这是一个令人兴奋的构建时代 :)

Skills一开始是由Claude发布的一种**为跨平台可移植性的开放标准。**它是指一个包含指令、脚本和资源的有序文件夹，代理可以动态发现并加载这些 文件夹，从而更好地完成特定任务。

一般来说，一个完整的Skill，包含以下文件：

为什么它能解决 Context 膨胀？

因为它采用了渐进式披露 (Progressive Disclosure) 的机制：

1. Discovery (扫描)：Agent 启动时，只读取 SKILL.md 里的 name 和 description。内存占用极小，只为了“知道有什么”。
2. Activation (激活)：只有当你的任务匹配到某个简介时（比如“处理 PDF”），Agent 才会动态加载完整的 SKILL.md 正文到 Context 中。
3. Execution (执行)：根据指令，按需调用 scripts 里的代码或读取 references 里的文档。

Skills有三个核心特点，也是它火起来的原因。

可组合。多个Skills可以协同工作，AI自动判断需要哪些，形成可复用的能力链。

可移植。同一个skill，Claude Code、Codex、Cursor、OpenCode都能用，不用改一行代码。

高效。只加载需要的，不浪费token和上下文长度。把上下文留给当下任务，而不是反复解释规则。

Agent Skills最大的改变就在于渐进式披露，其本质依然是行业中大家都在不断优化的提示词工程和上下文工程，其对提示词做了标准化拆分，通过在本地创建相关文件并控制文件的读取，只在Agent需要时自主且自动加载内容。

就单拿提示词来说，我们在调用MCP时总要描述很多的工具提示词，在没有执行前，工具描述先把 Context 占满了。

反观Skills，Agent 最初只加载多个 Skills 的元数据（每个 Skill 占用几百 token），当 Agent 认为需要使用某个具体的 Skill，就会读取这个 Skill.md 说明（几千 token）

Skill 里还可以无限嵌套下去，告诉 Agent，想要深入了解某个具体问题，还可以继续读取哪份文件。

官方文档：
https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

一、学习路径与方法

1. 打好根基，循序渐进：

   • 首要任务：必须首先熟练掌握“四季歌”。这是八字分析的第一步，用于判断日主在不同季节的先天旺衰和基本喜忌，从而定出命局的富贵贫贱基调。

   • 不要贪多求快：老师反复强调，在根基不牢时，不要看太多杂乱的知识，否则思路会混乱，变成“浆糊”。应该专注于核心基础，精专才能学好。

   • 先背诵，后简化：对于“四季歌”这类核心口诀，必须下功夫背诵熟记，理解其原理。只有在完全熟练之后，才能尝试使用简化方法去应用。在不熟的情况下追求捷径，心里会没底，判断不灵。

2. 学习步骤：

   • 第一步：拿到一个八字，首先用“四季歌”判断其季节喜忌，这已经能看出命局一半的高低好坏。

   • 第二步：在根基扎实后，再结合“财官”等十神知识，进一步分析格局和细节。

   • 第三步：结合大运走势。命局喜火，大运走东南木火之地则吉；命局喜水，大运走西北金水之地则吉。好运能提升层次，坏运则压抑发展。

二、核心学习态度与心法

1. 目的与心态：

   • 深层目的：学习命理浅层是看五行生克，深层是窥见“因果”。学习的最终目的不应是陷入对命运的焦虑或执着，而是调整心态、认识自我。

   • 改变自己：老师强调，命理学习者首先应该做到的是改变自己。改变自己很简单，就是“放好心态”——不要情绪化，不要名利化。当你心思清净（清气上升），运气自然会改善。如果自己都改变不了，就无法影响他人。

   • 避免学“郁闷”：如果学完后反而让自己郁闷了，那就学“坏”了。正确的学习应该让人“开悟”，看淡得失，无论有钱没钱都能心态平和。

2. 对“命”与“运”的认知：

   • 命里有时终须有：命局中固有的东西（如财官印）才是根本的、可能终身拥有的。

   • 运里有时一时有：大运带来的东西是阶段性的，运过则无，是“虚妄”。

   • 修为的作用：命里没有的东西，可以通过后天的修行和修为来改进。这指向了个人心态和行为的调整。

三、实用总结与简化技巧

• 四季月核心：无论什么五行，生于辰月、丑月（三月、十二月），首要需火来调候；生于未月、戌月（六月、九月），首要需水来滋润。

• 季节总原则：夏天生的八字普遍需要水调候；冬天生的八字普遍需要火温暖。这是快速判断的大方向。

总而言之，老师倡导的学习方法是：从背诵“四季歌”等核心口诀打下坚实基础开始，专注精研，避免杂学混乱。在学习过程中，要摆正心态，以认识自我、调整心性为目的，最终达到“清气上升”、豁达开悟的境界，而非被命运所困。

🔍 WHAT（是什么）

Skills 是一种应用层的架构模式，它将完成特定任务的专业知识、业务流程和最佳实践封装成可供 LLM 按需加载的”操作说明书”。

本质特征：

• 是一个结构化的 Markdown 文件（SKILL.md）+ 可选的脚本代码
• 是写给 LLM 看的 SOP（标准作业程序）
• 是可复用、可版本化、可共享的知识资产
• 不是 LLM 的原生能力，而是建立在 Function Calling 和 MCP 之上的上层建筑

文件结构示例：

1
2
3
4
5

skill-name/
├── SKILL.md         # 核心指令（LLM加载）
├── scripts/         # 脚本代码（LLM不加载）
├── references/      # 参考文档（按需加载）
└── skill.json       # 元数据（应用层使用）

🎯 WHY（为什么需要）

七大核心价值：

一句话总结：Function Calling + MCP 解决了”怎么调用工具”的技术问题，而 Skill 解决了”如何让 AI 专业地工作”的系统问题。

👤 WHO（谁负责）

Skill 涉及三个角色，职责清晰分离：

决策分工：

• 应用层负责：“有什么技能可用”（提供菜单）
• LLM 负责：“该用哪个技能”（根据菜单点菜）
• 开发者负责：“技能该怎么做”（写菜谱）

⏰ WHEN（何时使用）

适用场景：

触发时机：当用户请求匹配到某个技能的 description 时，LLM 会调用 activate_skill 激活该技能。

📍 WHERE（在哪里运行）

Skill 的运行环境是分层的：

flowchart TB
    subgraph Cloud[云端/本地]
        A[应用层 - Skill Registry]
        B[技能存储 - SKILL.md + scripts]
    end
    
    subgraph LLM[LLM 服务商]
        C[LLM 推理引擎]
        D[上下文 - 元数据 + 激活的指令]
    end
    
    subgraph Tools[工具层]
        E[MCP 服务器]
        F[外部 API/数据库]
    end
    
    A -- "注入元数据" --> C
    C -- "activate_skill" --> A
    A -- "提供工具描述" --> C
    C -- "调用工具" --> E
    E --> F

• 元数据：在 LLM 上下文中
• 完整指令：激活后加载到 LLM 上下文
• 脚本代码：在应用层执行（LLM 不加载）
• 工具调用：通过 MCP 标准化接入

🔧 HOW（如何工作）

5.1 核心机制：渐进式加载

5.2 完整调用流程

sequenceDiagram
    participant U as 用户
    participant L as LLM
    participant A as 应用层
    participant T as 工具(MCP)

    Note over L: 上下文有技能元数据列表
    
    U->>L: "审查这段代码"
    
    L->>L: 语义匹配，选择 code-reviewer
    
    L->>A: 返回 tool_calls
{name:"activate_skill", args:{name:"code-reviewer"}}
    
    A->>A: 验证权限，加载 SKILL.md
    
    A-->>L: 注入完整技能指令
    
    loop 按步骤执行
        L->>A: 调用工具（Function Calling）
        A->>T: 通过 MCP 执行
        T-->>A: 返回结果
        A-->>L: 注入结果
        L->>L: 决定下一步
    end
    
    L-->>U: 返回最终结果

5.3 关键技术点

📊 6.1 效果总结

🎯 终极总结

1
2
3
4
5
6
7

# Skill 的 5W1H 一句话版
WHAT  = 给 LLM 看的 SOP（标准作业程序）
WHY   = 让 AI 从"会调用工具"变成"懂业务地工作"
WHO   = 应用层管注册 + LLM做决策 + 开发者写内容
WHEN  = 需要多步流程、业务规则、稳定输出时
WHERE = 元数据在 LLM 上下文，脚本在应用层执行
HOW   = 元数据注入 → 语义匹配 → 激活 → 按指令执行

Skill 的本质：它是 Function Calling 和 MCP 之上的智能封装层，把 LLM 的灵活性（理解与决策）和应用层的确定性（流程与管控）完美结合，让 AI 真正成为能稳定处理复杂任务的”领域专家”。

搭建完openclaw 他的名字叫Assistant
想改一个名字，叫虾总9527

问了下deepseek，但不知道怎么描述这个需求，表述的都不对，不知道是个哪儿。

只能问问他自己

原来这是webchat界面上的默认设置。再去deepseek

让这么改

1
2
3
4
5
6
7
8

{
  "agents": {
    "defaults": {
      "model": "test-model",  // 临时测试
      "personality": "你的名字是虾总9527"
    }
  }
}

结果配置报错了，试了好几个方式都不行，去官网上查了查

看到一段示例：

https://docs.openclaw.ai/gateway/configuration-examples#recommended-starter

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  identity: {
    name: "Clawd",
    theme: "helpful assistant",
    emoji: "🦞",
  },
  agent: {
    workspace: "~/.openclaw/workspace",
    model: { primary: "anthropic/claude-sonnet-4-5" },
  },
  channels: {
    whatsapp: {
      allowFrom: ["+15555550123"],
      groups: { "*": { requireMention: true } },
    },
  },
}

因此我加了一段

1
2
3
4
5

identity: {
    name: "虾总9527",
    theme: "helpful assistant",
    emoji: "🦞",
  }

结果发现也报错了

怎么办呢？ 发现了一个有用的命令：
openclaw doctor –fix

openclaw doctor --fix 是 OpenClaw 的诊断修复命令，相当于一个”自动医生”工具。让我详细解释它的作用：

🏥 主要功能

1. 检查配置文件

• 扫描配置文件中的语法错误
• 检查配置项是否过时（比如你遇到的 identity 问题）
• 验证模型配置是否正确

2. 自动修复问题

• 自动迁移过时的配置项（如 identity → agents.list[].identity）
• 修复格式错误
• 补充缺失的必要配置项

3. 生成修复报告

会告诉你：

• 发现了什么问题
• 自动修复了什么
• 哪些问题需要手动处理

📋 实际效果

就像你之前看到的：

1
2
3
4

Config invalid
File: ~/.openclaw/openclaw.json
Problem:
  - identity: identity was moved; use agents.list[].identity instead

运行 openclaw doctor --fix 后，它会：

1. 自动帮你把旧的 identity 配置移到正确位置
2. 修改配置文件
3. 使配置生效

🔄 类似场景

相当于其他软件的：

• npm audit fix - 修复 npm 包问题
• git fsck - 检查 git 仓库完整性
• chkdsk - Windows 磁盘检查

✅ 使用建议

当你遇到配置相关错误时，第一步就应该运行：

1

openclaw doctor --fix

它会自动处理大部分常见问题。如果还有问题，会给出明确的提示告诉你需要手动修改什么。

最后，在界面上看到了效果

一号助手虾总9527诞生了。

MCP（Model Context Protocol，模型上下文协议）

2024年11月底，由 Anthropic 推出的一种开放标准，旨在统一大模型与外部数据源和工具之间的通信协议。

MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。

对于 LLM 开发者，MCP 是一个变革性的协议。

它消除了为每个数据源或工具进行定制集成的需要，减少了开发时间和维护成本。

从本质上来说，MCP是一种技术协议，一种智能体Agent开发过程中共同约定的一种规范。

在统一的规范下，协作效率就能大幅提高，最终提升智能体Agent的开发效率。

MCP协议本质就是Function calling技术的更高层封装和实现。

传统的Function calling技术要求围绕不同的外部工具API单独创建一个外部函数，类似一把锁单独配一把钥匙，而一个智能体又往往涉及到多个外部工具设计，因此开发工作量很大。

MCP 的灵感部分来源于 USB-C 的类比：如同 USB-C 通过统一接口连接多种设备，MCP 旨在为 AI 应用提供一个“即插即用”的上下文管理框架。

MCP 的核心思想是将模型与外部系统之间的通信抽象为一个客户端-服务器架构，通过标准化的接口（如基于 JSON-RPC 的通信）实现上下文的动态传递和工具的灵活调用。Anthropic 在发布时提供了初步的规范和 SDK（如 Python 和 TypeScript），并开源了多个预构建的 MCP 服务器（如 Google Drive、GitHub 集成），以加速该协议的推广。

MCP服务器与客户端

MCP技术体系中对大模型和外部工具的一种划分方式，也就是说在MCP技术体系中，会将外部工具称作服务器，而接入这些外部工具的大模型运行环境称作客户端。

MCP 客户端调用服务器工具的流程如下：

1、建立连接 ：与 MCP 服务器搭建通信链路。

2、查询工具 ：获取服务器上所有外部工具的数量信息。

3、生成列表 ：将查询到的外部工具整理成列表，并融入当前对话场景。

4、调用工具 ：通过 Function calling 技术调用所需的外部工具。

一个客户端可以接入多个不同类型的服务器的，但要求是都要遵循MCP通信协议。MCP服务器的输出内容是一种标准格式的内容，只能被MCP客户端所识别。在客户端和服务器都遵循MCP协议的时候，客户端就能够像Function calling中大模型调用外部工具一样，调用MCP服务器里面的工具。

VS Function calling

Function Calling是AI大模型模型调用函数的机制，

MCP是一个标准协议，使大模型与API无缝交互，

而AI Agent是一个自主运行的智能系统，利用Function Calling和MCP来分析和执行任务，实现特定目标。

ReAct（Reasoning + Acting）是一种将推理和行动相结合的 Agent 范式。在这个范式中，Agent 会：

1. 思考（Reasoning）：分析当前情况，决定下一步该做什么
2. 行动（Acting）：执行工具调用或生成最终答案
3. 观察（Observation）：接收工具执行的结果
4. 迭代：基于观察结果继续思考和行动，直到完成任务

这个循环使 Agent 能够：

• 将复杂问题分解为多个步骤
• 动态调整策略基于中间结果
• 处理需要多次工具调用的任务
• 在不确定的环境中做出决策

Spring AI Alibaba 中的ReactAgent 基于 Graph 运行时构建。Graph 由节点（steps）和边（connections）组成，定义了 Agent 如何处理信息。Agent 在这个 Graph 中移动，执行如下节点：

• Model Node (模型节点)：调用 LLM 进行推理和决策
• Tool Node (工具节点)：执行工具调用
• Hook Nodes (钩子节点)：在关键位置插入自定义逻辑

ReAct Agent 的工作方式其实挺像人类解决问题的过程。它不是一次性把整个流程都规划好，而是在有一个整体目标的前提下，走一步看一步。

具体来说，它会先观察当前的情况，然后思考下一步该做什么，接着执行这个动作，再观察结果，根据结果决定下一步。

这个过程会一直循环，直到任务完成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

函数 执行一个轮次(用户目标, 历史上下文):
    // 1. 获取当前环境信息
    当前环境信息 = 获取当前环境信息()
    
    // 2. 构建提示词（替换占位符）
    提示词模板 = "已知：\n当前历史上下文：${历史上下文}\n当前环境信息：${当前环境信息}\n用户目标：\"${用户目标}\"\n\n做出下一步的决策\n\n你必须最少使用一个工具来实现该决策"
    完整提示词 = 替换占位符(提示词模板, {
        历史上下文: 历史上下文,
        当前环境信息: 当前环境信息,
        用户目标: 用户目标
    })
    
    // 3. 调用 LLM 进行推理（思考过程隐藏，直接输出 toolcall）
    工具调用结果 = 调用语言模型(完整提示词, 历史上下文)
    
    // 4. 解析工具调用
    工具名称 = 解析工具名称(工具调用结果)
    工具参数 = 解析工具参数(工具调用结果)
    
    // 5. 执行工具调用
    观察结果 = 执行工具(工具名称, 工具参数)
    
    // 6. 更新历史上下文
    新历史上下文 = 追加到历史上下文(历史上下文, {
        行动: 工具调用结果,
        观察结果: 观察结果
    })
    
    // 7. 返回结果
    返回 {
        观察结果: 观察结果,
        新历史上下文: 新历史上下文
    }
结束函数

// 主循环
函数 执行ReAct流程(用户目标):
    历史上下文 = 空
    当前轮次 = 1
    最大轮次 = 10
    
    当 当前轮次 <= 最大轮次 且 未完成任务:
        结果 = 执行一个轮次(用户目标, 历史上下文)
        历史上下文 = 结果.新历史上下文
        
        如果 判断任务已完成(结果.观察结果):
            中断循环
        
        当前轮次 = 当前轮次 + 1
    结束循环
    
    返回 历史上下文
结束函数

最近股友推荐了一种复盘选择思路，想着正好让AI来干干呗

选股三步骤：

1、找到个股资金流向排行，点10日排行

2、排除法，超大盘子的，落后产能过剩产能的如房地产，行业太传统如钢铁，亏损的这些先剔除，然后按顺序翻看300只左右的股票，在其中选。连续十日增仓的都是强势股，在里面选择涨幅小，趋势好，行业独特的股票

3、连续10只增仓，连续十日资金流入的都是强势股，太强的，涨幅比较大的，也排除掉

把整个流程折成四步：

第一步：
1 浏览器打开数据中心 https://data.eastmoney.com/zjlx/detail.html
2 找到 个股资金流，使用 10日排行
3 抓取排名前2只股票，获取股票列表数据

最终以表格方式写入文件保存，一行一支股票, 表头是：股票号码|股票名称|10日涨幅,输出的文件包含表头内容，写到文件 stock_basic_data.md

第二步：
根据第一步输出的文件 stock_basic_data.md，先复制到stock_final_list.md

格式根stock_basic_data.md一样，在表头上增加两列所属行业 和 总市值

补充每行股票的所属行业和总市值信息

每只股票提取行业信息和总市值从下面的两个网址中提取，不需要点击其链接以查看详细信息

股票行业信息来源于网址：
https://emweb.securities.eastmoney.com/pc_hsf10/pages/index.html?type=web&code=SH600111&color=b#/gsgk

总市值信息来源于：https://emweb.securities.eastmoney.com/pc_hsf10/pages/index.html?type=web&code=SH600111&color=b#/cpbd，从概况页面提取总市值数值

信息提取完成后就关闭这个标签页

把提取到的所属行业和总市值信息写到文件 stock_final_list.md

一行一支股票, 表头是：股票号码|股票名称|所属行业|10日涨幅|总市值，输出的文件包含表头内容

第三步：
根据第二步输出的文文件 stock_final_list.md

你是资深财经专业人士，根据stock_final_list.md，各大财经网站和淘股吧精华贴等数据，总结，A股市场，1.热度总览2.第一梯队极度火热3.第二梯队局部高热4.第三梯队事件驱动5.第四梯队相对冷静，并对以上分析分别给出关键词和数据表现情况，最后给出整体总结及策略建议。然后，继续列表总结2月27日的连板梯队和跌停情况，以及对应的板块和题材。最后根据前述总结的内容用费曼学习法 1.先说结论 2.相应论点核心内容(前有序号） 3.总结 4.启示及未来行动指南及风险提示 5.奥卡姆剃刀总结

总结解读内容，除了以markdown格式输出一份文件 market_heat_analysis_{yyyyMMdd}.md，

再分析一下 linked_external/market_heat_analysis_20260227.html 里面的内容, 参照里面的格式，生成以HTML格式可视化保存到文件 linked_external/market_heat_analysis_{yyyyMMdd}.html

第四步：
分析一下 linked_external/index.html 里面的内容，

根据里面的格式,增加加一下 第三步生成的 linked_external/market_heat_analysis_{yyyyMMdd}.html 的内容，并链接到market_heat_analysis_{yyyyMMdd}.html

最后生成一份复盘记录，从中挑选喜欢的股票

https://zhuxingsheng.com/market/market_heat_analysis_20260302.html

不过最近股市天天吃大面。还要烧token

一、 掌握核心“量命的尺子”（歌赋口诀）

这是学好命理最关键的一步，用以保证论断的统一性和准确性。

• 必要性：歌赋是命理分析的“定义”和“公式”，如同数学的九九乘法表。没有这把“尺子”，分析同一个八字在不同阶段可能会得出不同结论，导致水平不稳定。

• 精选内容：无需背诵大量长篇歌赋，只需精选5到6首精华、精品的歌赋即可。

• 核心推荐：

  1. 《九窍歌》：完整概括了论命的九个步骤，是总纲。

  2. 《财官赋》（或相关论财官的歌赋）：是子平格局法的核心。

  3. 《四季歌》：关于五行在四季旺衰状态的基础法则。

• 目标：将这些歌赋背熟、弄懂、会用，达到“条件反射”的程度，就能自己开悟，打下坚实基础。

二、 理清分析逻辑，把握时空关系

在实战中，必须能清晰区分事情发生的时间点。

• 核心能力：将大运、流年与四柱（原局）的作用关系理清，判断事情是发生在过去、现在还是未来。

  • 与过去发生关系：可能是陈年旧事或六亲之事。

  • 与当下发生关系：是眼下正在进行的事。

  • 与未来发生关系：是今年新出现的事。

  • 新旧勾连：例如“新旧犯三刑”，代表新事勾起旧事，问题一并爆发。

• 避免错误：如果没有这个中心思想，容易把没有关系的干支强行解释为有关系，导致论断混乱。

三、 进行大量实践，做到理法结合

理论必须通过大量实战来印证和巩固。

• 重要性：再好的理论，没有实践也无法真正掌握。命理是“台下十年功，台上五分钟”的学问。

• 实践目的：通过大量案例，将歌赋理论融会贯通，锻炼从四柱、大运、流年中快速提取信息、理清脉络的能力。

四、 端正学习态度，认识体系深度

• 认识学习周期：从零基础到真正掌握，通常需要三到五年的持续学习。这是一个体系庞大的学问，不能急于求成。

• 抓住核心脉络：认清所有八字流派归根结底都源于 “虚中”（禄命法，重年柱） 和 “子平”（格局法，重月令） 两大体系。学习时要将二者融合看待（年主先天大框架，月主后天个人成就）。

• 不排斥必要元素：不要轻易否定神煞、胎元、命宫等传统要素的作用。它们是完整体系的一部分，能提高断事的精确度（所谓“不用神煞卦不灵”）。

五、 个人努力与天赋

• 承认个人在学习能力、天赋和努力程度上存在差异。即使师出同门，水平也会有高有低。

• 关键在于 “出于蓝而胜于蓝” 的自我追求和持续精进。

总结建议：

抓住“虚中”与“子平”两大核心脉络，精选并精通《九窍歌》、《财官赋》、《四季歌》等核心歌赋作为分析标尺，通过大量实战案例理清大运流年与命局的时空作用关系，并保持耐心，进行长达数年的系统学习和实践。 这是主讲人指出的高效学习路径。

之前一直在尝试开发一个Agent产品，配合公司垂直的专业软件。

简而总之一句话：借助AI能力，降本增效。现在谁不拥抱AI，谁就落后

使用spring-ai-alibaba的ReactAgent框架快速搭建了一个原型，通过chatbox的形式实现一个简单的场景

后来老板希望有深度思考能力，在chat的基础上再进一步，所以想研究一下manus，而阿里有个开源产品JManus：https://github.com/spring-ai-alibaba/jmanus

最近一直在尝试使用阿里开发的JManus产品

AI现在迭代相当快速，学习方式真不能像以前一样，慢慢挖原理，借助以前的学习经验尝试迁移，再实践试错。

像学习JManus，有了上一步ReactAgent基础，本打算看看源码，追加一些MCP或者Function Calling 来配合公司专业软件
但跟作者交流后，作者第一条就是不建议自己去实现tools

不过在使用中，也才慢慢体会JManus是个什么产品，所以现在AI时代，更加需要理论和实践结合，边做边学，做中学，学中做。

使用JManus的过程中，发现它的有些行为总不如意，所以还得多尝试下其他产品。试试OpenClaw

正好去年买了台云服务器，上手试一下，记录下部署过程。

直接执行官方一键安装脚本，无需手动配置依赖：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

curl -fsSL https://openclaw.bot/install.sh | bash

  🦞 OpenClaw Installer
  Your task has been queued; your dignity has been deprecated.

✓ Detected: linux

Install plan
OS: linux
Install method: npm
Requested version: latest

[1/3] Preparing environment
· Node.js not found, installing it now
· Installing Node.js via NodeSource
· Installing Linux build tools (make/g++/cmake/python3)
✓ Build tools installed
✓ Node.js v22 installed
· Active Node.js: v22.22.0 (/usr/bin/node)
· Active npm: 10.9.4 (/usr/bin/npm)

[2/3] Installing OpenClaw
✓ Git already installed
· Installing OpenClaw v2026.3.2
! npm install failed for openclaw@latest
  Command: env SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm --loglevel error --silent --no-fund --no-audit install -g openclaw@latest
  Installer log: /tmp/tmp.TXFT1VTDwD
! npm install failed; showing last log lines
! npm install failed; retrying

这失败应该是网速问题，换个国内镜像

1
2
3

# 先退出当前脚本（按 Ctrl+C）
# 设置淘宝 npm 镜像源
npm config set registry https://registry.npmmirror.com

1
2

# 手动尝试安装一次，看是否成功
npm install -g openclaw@latest --loglevel verbose

安装成功后，执行初始化命令，启动配置向导：

1

openclaw onboard --install-daemon

配置到模型时，注意一下，如果使用Qwen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Model/auth provider
│  ○ OpenAI
│  ○ Anthropic
│  ○ Chutes
│  ○ vLLM
│  ○ MiniMax
│  ○ Moonshot AI (Kimi K2.5)
│  ○ Google
│  ○ xAI (Grok)
│  ○ Mistral AI
│  ○ Volcano Engine
│  ○ BytePlus
│  ○ OpenRouter
│  ○ Kilo Gateway
│  ● Qwen (OAuth)
│  ○ Z.AI
│  ○ Qianfan
│  ○ Copilot
│  ○ Vercel AI Gateway
│  ○ OpenCode Zen
│  ○ Xiaomi
│  ○ Synthetic
│  ○ Together AI
│  ○ Hugging Face
│  ○ Venice AI
│  ○ LiteLLM
│  ○ Cloudflare AI Gateway
│  ○ Custom Provider
│  ○ Skip for now

只有OAuth方式，使用API Key方式，选择Custom Provider

阿里云百炼平台为兼容 OpenAI 风格调用提供的接口地址。北京地域： https://dashscope.aliyuncs.com/compatible-mode/v1

最后启动成功

但访问时，碰到几个问题：

control ui requires device identity (use HTTPS or localhost secure context)

这个错误触及了 OpenClaw 安全机制的核心。它说明您正通过公网 IP 的 HTTP 协议访问，但浏览器的安全策略要求要么使用 HTTPS，要么访问 localhost，才能进行设备身份验证。

🔍 问题的根源

OpenClaw 使用 WebCrypto API 进行设备配对和身份验证，而浏览器强制要求 WebCrypto 必须在安全上下文中运行 ：

• ✅ 安全上下文：HTTPS 或 localhost
• ❌ 非安全上下文：通过公网 IP 的 HTTP 访问

🛠️ 三种解决方案

方案1：快速测试（开发环境使用）
方案2：使用 SSH 隧道（推荐且安全）
方案3：配置 HTTPS（生产环境推荐）

📊 方案对比

disconnected (1006): no reason

在上面HTTPS问题上，因为我本身有HTTPS域名，就配置了ngnix

但websocket方式配置有问题，所以报了这个错。

有不明白的，直接deepseek，不过这个ngnix配置，使用千问真准一些，上次部署JManus也碰到了这个问题

pairing required

1
2
3
4
5
6

pairing required
此设备需要网关主机的配对批准。
openclaw devices list
openclaw devices approve <requestId>
在手机上？从桌面运行 openclaw dashboard --no-open 复制完整 URL（包括 #token=...）。
Docs: Device pairing

这是最后一个障碍了！这是设备认证机制，说明 OpenClaw 的安全机制在工作！

到时都成功了，可以正常使用了

大功告成，先问个经典问题：

后面就得尝试使用，怎么提升效率。