节点深耕 / Agentic

Agentic 工程实践：模块化、结果驱动、持续演进

本文将 Agent 开发流程拆为三条主线：模块化设计、结果驱动交付、持续演进机制，并给出可落地的组件映射与实践路径。

2026-02-01约 5 分钟阅读
#node/agentic #agentic #LLM #Prompt

借鉴软件工程经验，Agent 应用可以从三个维度推进：

  • 模块化：标准化职责、单一原则、提升复用性
  • 结果驱动：可测试、可验证、可回归
  • 持续演进：迭代优化、反馈闭环、版本管理

模块化 ​

Prompt ≈ Code Model ≈ Compiler Agent ≈ Application

粗浅地看，我们可以将 Prompt 视为一种新的高级编程语言。它具有更高的抽象能力和表达力，但同时也带来了新的挑战：

  • 不确定性：大模型的输出具有随机性和多样性，难以保证结果的一致性和可预测性
  • 黑盒性：大模型的内部机制和决策过程不透明，难以理解和调试
  • 依赖性：大模型的性能和行为受训练数据和模型架构的影响，难以控制和优化
  • 安全性：大模型可能产生有害、偏见或不适当的内容，难以防范和监管

同样地，我们可以将 Agent 视为一种新的应用架构，它具有更高的智能能力和自主性。

Agent 的核心组件 ​

System Instruction（系统指令） ​

定义全局规则、角色与安全边界，默认生效。

  • 类似于：Environment Variables 或 Global Configuration
  • 示例：SOUL.md、AGENT.md、CLAUDE.md

Command（命令） ​

用户主动触发的可执行命令。

  • 类似于：API Endpoint 或 CLI Command
  • 示例：帮我写一封邮件、/search AI safety papers

Skill（技能） ​

已掌握的可自主调用的能力。

  • 类似于：Dynamic Dispatch 进行条件匹配
  • 示例：pdf-convert、code-execution、web-search

上下文与数据层 ​

Memory（记忆） ​

跨会话状态与偏好，确保连续性。

  • 类似于：Database 或 Cache
  • 示例：User Profile Memory、Task State Memory

MCP（模型上下文协议） ​

外部能力接入层，为 Skill 和 Memory 提供数据与接口。

  • 类似于：3rd-party API
  • 示例：Github MCP、Google Search MCP

Agent 的封装与编排 ​

将上述各层组合成可交付的最小智能体单元，就可以像使用传统软件一样进行版本管理、权限控制、测试和迭代。

单个 Agent ​

将各层组合成可交付的最小智能体单元。

  • 类似于：Software Package 或 Service
  • 示例：Email Assistant Agent、Research Assistant Agent

Multi-Agent（多智能体） ​

多个 Agent 通过调度编排或自治协作完成复杂任务。

  • 类似于：Microservices Architecture
  • 示例：Customer Support System with Email Agent, Chat Agent, and Knowledge Base Agent
mermaid
flowchart TD
  subgraph CA[Agent]
    SI[System Instruction]
    MS[Command]
    AS[Skill]
    MCP[MCP]
    M[Memory]
  end

  U('User') --> CA
  SI --> MS
  SI --> AS
  MCP --> MS
  MCP --> AS
  M[Memory] --> MCP

  CA --> Prompt
  Prompt --> LLM

参考：Awesome Agentic Patterns

结果驱动 ​

为什么需要结果驱动 ​

大模型具备先天的不确定性与黑盒属性，试错与迭代是必要流程。因此，每个模块都必须满足以下要求：

  • 可测试：能够验证功能是否正常
  • 可复现：结果具有一定的一致性
  • 可校验：能够评估输出质量
  • 可回归：支持版本回滚和问题追踪

设计与开发应先定义验收标准和验证路径，再实现能力编排。不可测试 = 不可上生产。

从"代码"到"结果"的转变 ​

如果将 Prompt 看作一种编程语言，那通过 Agent 生成的产物就相当于软件工程中的"编译结果"（如 .class 文件）。大多数情况下，我们并不需要关注它，而应该关注结果 —— 即用户的目标是否达成、价值是否创造。过度关注代码细节，反而会陷入微管理，降低效率和创新。

"坚持不去看除了 CLAUDE.md 以外的代码。杜绝对 AI 的 micromanagement（微管理）。用 AI 是锻炼一个领导者的 servant leadership 的很好的办法。" —— 胡渊鸣 | 我给 10 个 Claude Code 打工

"守护架构，放权代码" ​

这是更高杠杆的工作方式：

  • 聚焦结果与价值，而不是逐行控制代码细节
  • 用边界与验收标准约束系统，而不是用微管理约束执行
  • 把精力放在架构、优先级与反馈闭环这些高 leverage 决策上

持续演进 ​

演进的必要性 ​

Agent 应该是一个持续演进的系统，而不是一次性交付的产品。通过以下方式不断提升 Agent 的能力和适应性：

  • 迭代优化：基于使用反馈持续改进
  • 反馈闭环：建立用户反馈的收集与应用机制
  • 版本管理：支持灰度发布、A/B 测试和快速回滚

设计原则 ​

从一开始就要考虑系统的长期可维护性：

  • 可维护性：清晰的模块划分和文档
  • 可扩展性：预留扩展接口，支持新能力接入
  • 可升级性：避免技术债务和过度耦合

个人实践 ​

Github Copilot ​

Customize AI in Visual Studio Code，Copilot 已经支持绝大多数的 Agentic 技术，包括：

  • .github/copilot-instructions.md = System Instruction
  • .github/prompts/*.prompt.md = Command
  • .github/skills/*/SKILL.md = Skill
  • MCP & Custom Agent

在不更改开发环境的情况下，通过自定义的指令逐步构建智能体工作流，最后替代大部分的重复性工作。如：/test-golang, /code-review, /debug-kubernetes, /get-my-jira-tickets ...

Memory ​

Memory 主要用于存储用户的偏好、历史交互和上下文信息，以便在跨 Session 的交互中保持连续性。实现方式：

  • 文件系统：将 Memory 存储在指定路径的文件中，将路径作为输入
  • 文件系统+skill：提供读写 Memory 的技能，无需提供具体路径，e.g. OpenSpec
  • MCP：将 Memory 存储在外部系统（数据库）中，通过 MCP 提供接口访问，e.g. OpenMemory

🤖 AI投喂建议：

  • “Command 和 Skill 的区别”
  • “Agent 的版本管理和回滚机制”
  • “如何测试和评估 Agent 的输出质量”