上个月面试一个候选人，简历很漂亮，做过三年 LLM 应用开发。我问他：「你觉得你做的东西，本质上是在交付什么？」
他说：「交付模型能力。把 LLM 的能力封装成 API，让业务方能用。」
我又问：「如果业务方说，我要一个能自主完成端到端任务的系统，不只是回答问题——你交付的东西能做到吗？」
他愣了一下：「那得加很多工程，不只是调 API。」
我说：对，这就是我今天想聊的——当交付物从「模型能力」变成「自主系统」时，你的工程标准该是什么样。
一个被用滥的词：Agent
今天几乎所有 LLM 应用都自称 Agent。但如果你仔细看，90% 的「Agent」本质上是一个 Chatbot + Tool Calling：用户说一句，它调一个 API，回一句。没有循环，没有状态，没有自主性。
这不是 Agent。这是 带工具的聊天机器人。
如果类比计算机科学，一个真正的 Agent 应该像一台图灵完备的计算机： 给定足够的时间、上下文和工具，它能完成任何可计算的任务。这比「能回答问题」的要求高得多。
我把这种 Agent 叫做 图灵完备 Agent（Turing Complete Agent）。
十个能力维度
一个图灵完备的 Agent，至少应该具备以下十个能力。这不是一个 checklist，而是一个 能力光谱——你可以用它来判断你的 Agent 处在哪个阶段。
1. 无限循环（Loop）
不是一次 Prompt → 一次 Response。而是：
while not task_finished:
think()
plan()
act()
observe()
learn()
# generated by hugo AI
举个例子：收到一个复杂任务 → 拆解 → 调用工具 → 发现失败 → 修改方案 → 继续执行 → 直到完成。 没有 Loop，就不是 Agent。
今天大部分所谓的 Agent，本质上是单次请求-响应。用户不问，它就不动。这不是 Agent，这是 被动的工具。
2. 可读可写的 Memory
LLM 的 Context Window 不是真正的 Memory。Context 是一次对话的短期记忆，关掉窗口就没了。
真正的 Memory 应该分层：
Working Memory → 当前任务的上下文
Long-term Memory → 用户偏好、公司规范、SOP
Semantic Memory → 领域知识、概念关系
Episodic Memory → 做过什么、发生过什么
Procedural Memory → 学会的新技能、工作流
而且 Memory 必须支持完整的 CRUD 操作： Read、Write、Search、Update。否则 Agent 无法长期成长，每次启动都是一个失忆的新进程。
这一点我在 数字员工 MVP 指南 里也强调过——知识库不是一次性工程，而是持续运营的服务。Memory 更是如此。
3. 无限扩展的 Tool Calling
工具不是几十个固定 API。而是 任何可编程的接口：
MCP Server
CLI 命令
HTTP API
Browser 自动化
Database 查询
IM 消息
SaaS 集成
文件系统
Agent 的能力上限来自 Tool，而不是模型本身。一个只有 5 个工具的 GPT-4，不如一个有 50 个工具的 GPT-3.5。 工具的数量和质量，决定了 Agent 能做什么。
4. 自己生成新 Tool
这是真正拉开差距的能力。当 Agent 发现重复工作时，它应该能：
识别重复模式 → 写代码（Python/Go）→ 生成 MCP Server → 部署 → 以后直接调用
Agent 可以 创造自己的能力。这一步非常重要——它意味着 Agent 不再是静态的工具集，而是一个 自我扩展的系统。
5. 动态修改 Workflow
Workflow 不应该是一个写死的 DAG（有向无环图）。它应该能根据执行情况动态变化：
第一次执行：A → B → C
发现 B 是瓶颈后：A → Planner → Parallel(B1, B2, B3) → Verifier → Merge
Workflow 是 Agent 的「程序」，程序应该能被 Agent 自己修改。这才是真正的自主性。
6. 创建新的 Agent
Agent 可以组成树：
CEO Agent
├── 采购 Agent
├── 法务 Agent
├── 销售 Agent
└── 开发 Agent
├── 前端 Agent
└── 后端 Agent
这已经非常接近操作系统里的 Process。Agent 可以 fork 子 Agent，子 Agent 可以有自己的 Memory、Tool、Identity。Multi-Agent 不是多个 Chatbot 聊天，而是 进程间协作。
7. 并发执行
四个 Agent 同时工作：
Research Agent ─┐
Coding Agent ├─→ Merge → Final Output
Testing Agent │
Documentation Agent─┘
不是串行。是真正的并发 + 协调。这需要 Scheduler、需要 IPC（Agent 间通信）、需要同步机制。
8. 反思（Reflection）
执行之后，Agent 应该能复盘：
为什么失败？
哪里慢了？
Tool 是否可靠？
Prompt 是否需要更新？
Memory 里有没有过时信息？
然后更新自己的 Memory、Workflow、Skill、Prompt。 没有反思的 Agent，永远不会进步。
9. 暂停与恢复
Agent 不应该一直在线。它应该能：
Checkpoint → 退出 → 一天后恢复 → 继续执行
像操作系统里的 Process，可以被挂起、被唤醒。这是长程任务的基础——一个需要跑几天的任务，不可能要求 Agent 24 小时在线不中断。
10. 有身份（Identity）
每个 Agent 应该拥有：
Name、Role、Permission、Credential
Memory、Knowledge、Skill、Communication
它不是一次 Chat。它是企业里的一个 员工。这一点我在 Claude Tag 的 Agent Identity 里详细讲过——Agent 没有身份，就只能借用人的身份，这在企业场景下是不可接受的。
从计算机角度看 Agent
如果把 Agent 类比成操作系统，映射关系非常清晰：
| 计算机 | Agent |
|---|---|
| CPU | LLM 推理能力 |
| RAM | Context + Working Memory |
| Disk | Long-term Memory |
| Program | Prompt / Skill / Workflow |
| Syscall | Tool Calling |
| Process | Agent |
| Fork | 创建子 Agent |
| IPC | Agent 通信 |
| Network | MCP / API / Browser |
| Scheduler | Planner / Orchestrator |
这个类比不是比喻，而是 工程实现的同构。今天很多 Agent 框架在重新发明轮子——调度器、权限系统、状态管理、进程间通信——这些东西在 Unix 里已经存在了 50 年。
我在 AI Agent 架构：Unix 哲学的回归 里详细论证过这个观点： Agent Runtime 本质上是在重新发明 Unix。
所以未来真正的 Agent Runtime，很像一个 AI 操作系统，而不是一个聊天窗口。
一个更完整的定义
综合以上，我把 图灵完备 Agent 定义为：
一个拥有推理能力（LLM）、无限循环（Loop）、持久记忆（Memory）、可扩展工具（Tools）、动态工作流（Workflow）、自我演化（Learning）、多 Agent 协作（Multi-Agent）以及自主执行能力（Autonomy）的运行时系统。
其中， LLM 只是它的「CPU」。真正决定 Agent 上限的，是 Runtime。
今天大部分团队还在优化「CPU」——换更大的模型、做更好的 Prompt Engineering。但一个只有强 CPU 而没有操作系统、没有文件系统、没有调度器的机器，只是一块芯片，不是一台计算机。
对企业数字员工的启发
如果把企业里的数字员工作为目标，那么一个成熟的 Agent Runtime 可以进一步抽象为核心原语：
Agent
├── Identity（身份、权限、凭据）
├── Memory（工作记忆、长期记忆）
├── Loop（持续运行）
├── Planner（任务规划）
├── Skills（可复用技能）
├── Tools（CLI、MCP、API、Browser、DWS 等）
├── Knowledge（企业知识）
├── Communication（IM、邮件、会议）
├── Scheduler（定时、事件触发）
├── Multi-Agent（创建与管理子 Agent）
└── Reflection（复盘与持续优化）
# generated by hugo AI
从工程实现来看，这些能力共同构成了一个 Agent Runtime，而不是单一模型能力。模型负责推理，Runtime 负责状态、执行、协作和生命周期管理。
这也是许多团队从「聊天机器人」走向「数字员工」时需要跨越的关键一步——不是换个更大的模型，而是建一个更完整的 Runtime。
工程师的交付物变了
回到开头那个候选人。他的问题不是技术能力不够，而是 对「交付物」的理解还停留在上一个时代。
在 Web 时代，工程师交付的是 页面和功能。在移动时代，交付的是 App 和 API。在 AI 时代，交付的应该是 Agent——一个能自主完成任务的运行时系统。
这个转变的深层含义是：
- 从交付代码到交付能力：代码是手段，Agent 是目的
- 从交付功能到交付自主性：功能是固定的，自主性是通用的
- 从交付工具到交付员工：工具被动等待，员工主动执行
在 从做网站到做 Agent：工程师没变，交付物变了 里，我详细讲过这个转变的 career implication。这里我想补充的是： 交付物的标准也变了。
过去交付一个 Web App，你会看性能、可用性、代码质量。今天交付一个 Agent，你应该看 图灵完备性的十个维度——它能循环吗？有记忆吗？能扩展工具吗？能并发吗？能反思吗？
这不是过度设计。这是 定义什么是「好」的 Agent 的工程标准。
从 Chatbot 到 Turing Complete Agent 的路径
不是所有场景都需要图灵完备的 Agent。但作为工程师，你应该知道 终点在哪里，才能判断当前处在什么阶段、差距有多大。
Level 0: Chatbot（单轮问答）
↓
Level 1: Tool-Using Bot（带工具的聊天机器人）
↓
Level 2: Simple Agent（有循环、有记忆、能调用工具）
↓
Level 3: Autonomous Agent（能自主规划、动态修改 Workflow）
↓
Level 4: Multi-Agent System（多 Agent 协作、并发执行）
↓
Level 5: Self-Evolving Agent（能生成新工具、修改自己、反思学习）
今天大部分「Agent」还卡在 Level 1。少数到了 Level 2。Level 3 以上的，在工程实践里还非常罕见。
但这不意味着你不需要瞄准 Level 5。 正如你写一个排序算法时知道 O(n log n) 是最优复杂度，即使当前数据量小到 O(n²) 也能跑——知道上限，才能做出正确的工程取舍。
总结
AI 时代的工程师，交付的不是代码，不是功能，不是模型能力——而是 图灵完备的 Agent。
这不是一个遥远的愿景。这是一个 工程标准——用来判断你的 Agent 处在什么阶段、还缺什么能力、下一步该补什么。
LLM 只是 Agent 的 CPU。真正决定上限的，是 Runtime。而构建这个 Runtime，正是 AI 时代工程师的核心工作。
你觉得你的 Agent 处在哪个 Level？欢迎留言讨论。