Agent 进入企业，还差一个工位

七月的 WAIC 展馆，人声鼎沸。

大模型展台前挤满了人，Demo 屏幕上的 Agent 行云流水——自动写代码、自动做报表、自动回客户邮件。观众鼓掌，媒体拍照，投资人交换名片。

然后你回到公司，打开内部系统，发现你的 Agent 连个工号都没有。

它没有账号登录 CRM，没有权限查数据库，没有工位接收任务，出了错不知道找谁。它站在企业大门外，能力满分，但进不来。

阿里巴巴资深技术专家谢吉宝在 WAIC 2026「从大模型到智能体：迈向自主智能新纪元」论坛上说了一句大实话： 绝大多数 Agent 还站在企业门外，瓶颈已从模型能力转向组织兼容性。

他的解法是：给 Agent 一个工位。

工位五层模型

新员工入职第一天，HR 会给他办五件事：发工牌、开权限、配电脑、建档案、签责任书。Agent 也需要这五件事，一件都不能少。

这五层不是技术架构，是 组织架构。你可以用最好的模型、最快的推理、最便宜的 Token，但如果这五层缺任何一层，Agent 就只是一个站在门口的临时工。

工程实践：企业级 Agent 基础设施怎么建

过去半年，我们在内部跑了一套数字员工体系。不是 Demo，是 7×24 在线、有审计、有权限隔离、有人兜底的真实生产环境。以下逐层拆解基础设施选型和工程决策。

身份与持续在线：Managed Agent Runtime

Agent 不能「用的时候开，不用的时候关」。新员工不是你需要他的时候才让他来上班。

但「保持在线」只是最底层的需求。企业级 Agent Runtime 要解决的是 生命周期管理——启动、健康检查、异常恢复、优雅降级、版本升级，全链路可观测。

我们的做法是把 Agent 当作一个 长驻微服务 来治理，而不是一个脚本：

┌─────────────────────────────────────────────────────────┐
│              Managed Agent Runtime 架构                   │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌───────────┐    ┌───────────┐    ┌───────────┐       │
│  │ Supervisor │───▶│ Health    │───▶│ Auto      │       │
│  │ (进程守护)  │    │ Probe     │    │ Recovery  │       │
│  │            │    │ (30s 心跳) │    │ (3 次重试) │       │
│  └───────────┘    └───────────┘    └───────────┘       │
│       │                                    │            │
│       ▼                                    ▼            │
│  ┌───────────┐    ┌───────────┐    ┌───────────┐       │
│  │ Graceful  │    │ Version   │    │ Circuit   │       │
│  │ Shutdown  │    │ Rollout   │    │ Breaker   │       │
│  │ (排空任务) │    │ (蓝绿切换) │    │ (熔断降级) │       │
│  └───────────┘    └───────────┘    └───────────┘       │
│                                                         │
└─────────────────────────────────────────────────────────┘
# generated by hugo AI

关键工程决策：

• Supervisor 层：用 systemd / launchd 做进程守护只是第一步。我们在上面叠了一层自定义 Supervisor，负责心跳上报、任务队列排空、内存水位监控。进程活着不等于服务健康——一个卡死在死锁里的 Agent 进程，ps 看着正常，但已经 30 分钟没处理任何消息了。
• Health Probe：每 30 秒向 Runtime 上报心跳，包含当前任务数、最近一次成功响应时间、Token 余额。连续 3 次心跳超时触发 Auto Recovery——先尝试 graceful restart（排空当前任务再重启），失败则 force kill + cold start。
• Circuit Breaker：当某个外部依赖（比如 LLM API）连续失败 5 次，Agent 自动进入降级模式——停止主动任务，只保留被动应答，同时告警通知运维。不是等它把错误放大到不可收拾才干预。

@dataclass
class AgentHeartbeat:
    """Agent 每 30 秒上报一次的健康快照"""
    agent_id: str
    timestamp: datetime
    active_tasks: int
    last_success_at: datetime
    token_balance: int
    memory_rss_mb: float
    error_count_last_5min: int

    @property
    def is_healthy(self) -> bool:
        idle_too_long = (datetime.now() - self.last_success_at).seconds > 300
        overloaded = self.active_tasks > 10
        leaking = self.memory_rss_mb > 2048
        return not (idle_too_long or overloaded or leaking)
# generated by hugo AI

这不是什么高深技术，但据我观察，绝大多数 Agent 部署连心跳都没做——它们活在某个工程师的终端窗口里，关了就没了，卡死了没人知道。

权限：最小权限 + 动态升级

一个数字员工不应该同时拥有财务系统和代码仓库的权限。就像财务部的员工不应该有生产环境的 root 密码。

但企业级权限不是简单的「给 / 不给」二选一。真实场景是：Agent 平时只需要只读权限，但在执行特定任务时需要临时提权——就像员工平时不能动生产数据库，但 oncall 时可以申请临时权限，用完自动回收。

我们的权限模型分三层：

~/.hermes/profiles/
├── default/          # 通用助手：只读搜索 + 文档
├── coding/           # 编码员工：代码仓库 + CI/CD + 终端
│   └── escalation.yaml   # 动态提权规则：merge to main 需要人类 approve
├── ops/              # 运维员工：监控 + 告警 + 有限重启权限
│   └── escalation.yaml   # 动态提权规则：重启生产服务需要 oncall 确认
└── finance/          # 财务员工：报表系统（只读）+ 审批流
    └── escalation.yaml   # 动态提权规则：任何写操作都需要财务总监确认

每个 profile 有独立的 skills、plugins、cron 和 memories。coding profile 的 Agent 看不到 finance 的数据，finance 的 Agent 碰不到生产环境。

关键设计原则： 权限不是限制 Agent，是保护组织。 而且权限模型必须能回答一个问题——「如果这个 Agent 被 Prompt 注入了，最坏情况是什么？」答案应该是：最坏也就是它 profile 里那些权限能做的事，而不是整个系统沦陷。

审计：结构化操作日志 + 不可篡改

新员工试用期有导师盯着。Agent 的「导师」是审计日志。

但审计日志不是 print() 打几行 log 就完了。企业级审计要满足三个条件： 结构化 （可查询、可聚合）、 不可篡改 （Agent 自己不能删自己的日志）、 可关联 （一次任务的所有操作能串起来）。

我们的审计日志是 NDJSON 格式，每条记录带 trace_id 做任务级关联：

{"ts":"2026-07-25T14:32:01Z","trace_id":"task-8f3a","agent":"coding-agent","event":"TOOL_CALL","tool":"terminal","args":"git push origin main","risk":"low"}
{"ts":"2026-07-25T14:32:03Z","trace_id":"task-8f3a","agent":"coding-agent","event":"CONNECT","target":"github.com:22","status":"OK"}
{"ts":"2026-07-25T14:35:17Z","trace_id":"task-9b2c","agent":"coding-agent","event":"TOOL_CALL","tool":"terminal","args":"npm publish","risk":"high"}
{"ts":"2026-07-25T14:35:18Z","trace_id":"task-9b2c","agent":"coding-agent","event":"BLOCKED","reason":"profile_policy: npm publish not in allowed_commands","escalated_to":"human-oncall"}

最后一条是关键：Agent 试图执行 npm publish，被 profile 策略实时拦截，同时自动升级给人类 oncall。没有审计日志，你不会知道它试过。没有拦截策略，它已经发出去了。没有 trace_id，你事后排查时无法还原完整上下文。

日志写入独立的 append-only 存储（我们用的是一个单独的日志目录 + 定期归档到对象存储），Agent 进程对它只有写权限，没有删改权限。

我在 Agent 安全是企业安全的新命题 里详细讨论过执行控制体系。工位模型里的「责任」层，本质上就是把那套执行控制落到日常运维里——不是事后追责，是实时可观测 + 实时拦截。

记忆：分层状态管理

大多数 Agent 的「记忆」就是当前对话的上下文窗口。关掉窗口，一切归零。

这不是记忆，这是金鱼。

企业级 Agent 的记忆是一个 分层状态管理系统，不同层级的信息有不同的生命周期和访问模式：

新员工入职三个月后应该比第一天更懂业务，Agent 也应该如此。我们的数字员工每次完成任务后，会自动把关键决策和踩过的坑写入长期记忆。下次遇到类似问题，不用从零推理——直接调用历史经验。

这不是 RAG。RAG 是「从文档里找答案」，记忆是「我自己经历过，我知道该怎么做」。

从 70 分开始：人机协同的正确姿势

给 Agent 办了入职，下一个问题是：你期望它第一天就 100 分？

新员工入职第一周，你不会让他独立做架构决策。你会让他先做确定性高的事——写单元测试、整理文档、跑数据报表。做得好了，逐步扩大职责。

Agent 也一样。我们的实践原则是： 从 70 分开始。

• Agent 负责确定性工作：格式转换、数据清洗、代码生成、日志分析、定时播报。这些事有明确输入输出，做对了是 70 分，做错了能立刻发现。
• 人负责判断与决策：方案选型、优先级排序、异常处理、对外沟通。这些事没有标准答案，需要经验和直觉。

不要等 Agent 到 100 分再用它。70 分的 Agent + 30 分的人类判断，比 100 分的人类单独干更快、更稳。

这不是妥协，是分工。就像你不会因为实习生不能独立做架构就不让他写代码。

我在 拟人化的数字员工 里讲过，数字员工和聊天机器人的区别不在能力上限，在行为模式——主动做该做的事，知道什么不该做。70 分原则正是这种行为模式的落地： 确定性范围内主动，不确定性边界处上报。

行业判断：瓶颈从智能转向治理

WAIC 展馆里的 Agent Demo 越来越惊艳，但企业 CTO 们关心的已经不是「模型够不够聪明」。

他们关心的是：

• 这个 Agent 删了我的数据库谁负责？
• 它的操作能不能审计？能不能回滚？
• 它今天表现好，明天会不会因为一次 Prompt 注入就叛变？
• 我能不能像开除一个不合格的员工一样，干净利落地收回它的所有权限？

这些问题没有一个是模型能力问题。全部是治理问题。

我在 企业打造 AI 原生组织 里提过，AI 转型的瓶颈不在技术层，在组织层。工位五层模型是同一个判断的操作化表达： AI 落地不是一个技术集成项目，是一个组织管理项目。

模型厂商在卷参数、卷推理速度、卷多模态。但企业真正需要的下一步，是卷治理——身份体系、权限模型、审计基础设施、责任归属机制。谁先把这些做成标准化产品，谁就拿到了企业 AI 的入场券。

展望：从单兵到工位网络

今天大多数企业的 Agent 部署还是「单兵模式」——一个 Agent 干一件事，互相不通信，没有协作。

但新员工入职后不是孤立工作的。他有团队、有上下游、有汇报线。Agent 也会走向同样的路径：

趋势一：Agent 工位标准化。 就像企业有标准的工位配置（电脑 + 显示器 + 网络 + 权限），Agent 也会有标准的「工位模板」——身份、权限、工具、记忆、责任五层打包，开箱即用。

趋势二：Agent 团队协作。 多个 Agent 组成「数字团队」，有分工、有交接、有升级机制。编码 Agent 写完代码，测试 Agent 跑用例，运维 Agent 做部署，出了事上报给人类 Tech Lead。

趋势三：人机混合编制。 团队里同时有人类和 Agent，用同一套项目管理工具，看同一块看板，参加同一个站会。Agent 不是「辅助工具」，是编制内的同事。

这三个趋势的前提，都是工位。没有工位的 Agent 是临时工，有工位的 Agent 才是正式员工。

回扣：入职第一天

回到 WAIC 展馆。

那些在 Demo 屏幕上大放异彩的 Agent，回到企业现实里，缺的不是更聪明的脑子，是一个工号、一套权限、一台电脑、一份档案、一条汇报线。

新员工入职第一天，HR 不会问他「你有多聪明」。HR 会说：「来，先办手续。」

Agent 也一样。

先办手续，再谈能力。

你在企业落地 Agent 时，卡在五层中的哪一层？欢迎留言讨论。

See also

• 招 Agent 工程师，我第一个看的不是技术
• 拟人化的数字员工：不是会聊天的机器人，是能胜任岗位的数字同事
• Agent 应用工程师——AI 时代增长最快的新岗位
• 两个数字员工，一个组织：企业数字员工开发最佳实践
• 数字分身和数字员工的分界线：不是能力，是服务关系