夜雨聆风看了两天 Claude Managed Agents。它给每个 Agent 单独分配了运行环境、独立身份、成本统计、审计日志，还能跨会话恢复现场。看着看着我突然反应过来：这套东西的形态，跟公司给员工配工位、发工号、记考勤、走审批的那一整套，几乎是一一对应的。
那一刻挺有意思。我们一直在聊"模型变强"、"Agent 能力上限"，但真正在底层悄悄发生的事，是另一件——软件第一次开始具备员工属性了。
先想象一个不远的早晨。
你打开电脑，最先看到的不是办公消息，也不是 Jira 看板，是一份昨晚的工作汇报：你手下挂着的那几个 Agent，有几个跑通了，有几个卡在分支选择上等你拍板，还有几个在后台烧着 token。最下面一行小字，告诉你这帮家伙这个月已经花了多少钱。
你会突然发现，自己的工作不再只是亲自下场做事，还多了一层：管 Agent。
再往前推一步。一家三个人的小公司，花名册上挂着 47 个 Agent。每个 Agent 有名字、岗位、权限、成本中心、负责人和产出记录。到那时，"公司有多少人"这个问题，可能就没那么好回答了。
再极端一点。某天 HR 跟一个团队 leader 谈话，问的不是"你们今年招几个人"，而是"你们组这季度的 Agent 预算超了 30%，能不能解释一下"。第一次，管理者得为自己手下的 AI 负责，就像过去为自己手下的人负责一样。
听上去都还挺远。但这些画面背后的工程活儿，已经在动手做了：给软件实体发身份、分环境、记日志、设权限、算成本、做审计。
行业里现在会把这一层叫 Harness、Runtime、Agent Infra。名字都很技术，落到工作现场里看，做的事其实挺朴素：软件开始有点像能接活的人了，那就得照着管人的那一套，给它配一套。
为什么这次不一样
以前的软件大多是工具。
Word、Photoshop、Excel，甚至 Copilot，都还是这个逻辑：人来做事，软件在旁边帮忙。人是主语，软件是宾语。
Agent 开始把这个关系扭过来。
你跟 Claude Code 说：“修一下这个老 bug。”然后你去开会、吃饭、睡觉。它自己读代码、跑测试、改文件，再跑测试，再改。等你回来，它告诉你结果，顺便告诉你哪里卡住了、哪些地方需要你确认。
这一刻，软件不只是“被使用”的东西了。它开始像一个拿到任务的人。
所以它也会带来一串以前软件不太需要面对的问题：你得知道是谁干的，它得有地方跑，它昨天干到哪今天得能接上，它不能随便碰生产数据库，它花了多少 token 要能算账，它删了文件要能复盘。
这些东西凑在一起，就不只是一个更强的工具栏了。它更像一套给软件员工准备的管理系统。
Agent 时代真正难的地方就在这里。模型聪明，只是开始。让这份聪明进入一个组织——能干活，能留痕，能交接，能被限制，也能被问责——才是真正折磨工程师的部分。
给软件发工号：Session
人进公司，第一件事是有身份。工号、邮箱、合同、权限，都挂在这个身份下面。
Agent 也需要类似的东西。这个东西通常叫 Session。
你给 Agent 派一个长任务，系统会创建一个 Session。它像这次工作的工号：动作、产出、工具调用、花费、失败记录，全都挂在这里。
没有 Session，几个 Agent 同时干活很快就会乱成一团。某个文件被改坏了，你不知道是哪一次任务改的；某条命令跑炸了，你不知道是谁触发的；昨天没干完的事，今天也不知道该从哪接。
有了 Session，事情才有了线索。它不只是一个 ID，更像一根线，把一次工作的前因后果串起来。
给软件发工位：Sandbox
讲个我自己的小事故。
有一次我让一个 Agent 帮我跑一个老 Python 项目的测试。它发现依赖装不上，自作主张升了几个包的版本，把锁文件也改了。测试是跑过了，但接下来另一个项目，本来在我本机一切正常，突然全线挂掉——共享的解释器环境被它顺手改坏了。我当时盯着报错看了二十分钟，才反应过来是上一个 Agent 留下的"礼物"。
人上班要有工位。Agent 真正干活时，也需要自己的工位。这个工位通常叫 Sandbox。
只要它会装依赖、改文件、跑命令，就会污染环境。今天装的 Python 包可能影响明天的任务，A 任务留下的临时文件可能影响 B 任务的测试，一旦跑歪了，整台机器都能被弄得很脏。
所以"一任务一环境"会越来越像底线。Environment 是公司统一配好的标准工位，Session 是这次具体工作的现场，Sandbox 是边界：你可以在这里折腾，但别把隔壁的桌子也掀了。
文案、客服那类轻量 Agent 可能用不到这么重的隔离。但只要它真的碰代码、碰依赖、碰文件系统，没有 Sandbox 就有点像让新员工直接在生产机器上裸操作。短期看着省事，长期一定会出事故——我那次只是丢了二十分钟，下一次可能就是一个生产数据库。
Event Log：它每一步都得留下痕迹
人在公司干活，会留下很多痕迹。Git 提交、Jira 状态、会议纪要、Slack 讨论。平时看着琐碎，出了事就知道它们多重要。
软件员工也得留下这种痕迹。Event Log 就是它的工作日志。
它什么时候调用了哪个工具，输入是什么，返回了什么，谁批准了高风险操作，哪一步发生了 compact，哪个 checkpoint 可以恢复到，这些都不能只是在屏幕上刷过去。流式 token 让人看到过程，但系统要能管理过程，就得把关键动作记成结构化事件。
有了 Event Log，崩了能恢复，出事能审计，多 Agent 协作时也能串起来。task_created、agent_started、message_sent、tool_completed、agent_idle、task_completed，这些事件连在一起，就是 Agent 的协作轨迹。
这里有个常被搞混的点：流式 token 和结构化事件不是一回事。前者像你看见同事在工位上敲键盘，后者像公司系统里的工单记录。一个给人看，一个给系统用。两者都要有。
Harness：模型不能想干啥就干啥
新员工入职，公司不会直接给 root 权限。能看哪些文档，能访问哪些系统，能不能动生产数据，都是按岗位来的。重要操作还得审批。
Agent 进了"公司"，也得过这一关。Harness 大致就是它的工作规程和审批系统。
模型说“我要跑 npm test”，Harness 不能直接当传话筒。它要看这条命令安不安全，当前模式允不允许，要不要让用户确认，日志太长怎么截断，stderr 怎么处理，测试失败后怎么把错误重新整理给模型。
模型说“我要改 app.tsx”，Harness 也不能直接覆写。它要检查路径，确认文件是否读过，展示 diff，处理失败和回滚。
这就是为什么同一个底层模型，放在不同产品里会像两种东西。Claude 网页版主要服务聊天场景，更多是在回答；Claude Code、Devin 这类产品，真正拉开差距的是工程长任务里的 Harness：Query Loop、Context 管理、Tool System、Permission、Memory、Compact、Session Resume、Hooks，还有 MCP、Skill、Plugin 这些扩展机制。
模型让 Agent 有脑子，Harness 让它能上岗。
Runtime：让 Agent 能跨天活下去
有工号、工位、考勤和权限还不够。它们还得被一套环境托起来，就像公司不只需要花名册，还要有办公室、水电网、门禁、电梯、消防和档案系统。
这就是 Runtime。
Runtime 不太关心模型这一秒怎么推理。它关心的是另一件事：任务跑几个小时，中间网络断了，机器重启了，用户第二天才回来，这个 Agent 怎么继续活着。
短问答 Chatbot 不太需要这套东西。一句话答完，会话也就结束了。
长任务 Agent 是另一个物种。它要先创建 Session，再启动 Sandbox，把代码仓库、环境变量、依赖都准备好。接着开始一轮轮读文件、改代码、跑测试。遇到高风险操作，它会停下来等审批。没有新指令时，它可能进入 idle，环境还挂着，任务还没结束。过程中，系统不断写 Event Log，阶段性保存 Checkpoint。第二天用户回来，再从 Session 或 Checkpoint 把现场接上。
看到这里，Runtime 就不是一个抽象名词了。它更像办公室里的工位系统、门禁、工单、档案柜和断电保护。
它不决定 Agent 此刻聪不聪明，却决定它能不能像一个长期工作的执行体那样，稳定存在、出事可查、断了能续。
顺便说一句，Harness 和 Runtime 这两个词经常被搅在一起。简单分一下：Harness 管"怎么干活"——这一轮能做什么、不能做什么、怎么审批、怎么留痕；Runtime 管"怎么活着"——工号、工位、考勤、档案、上下班机制。一家公司缺哪个都跑不动，Agent 也一样。
Agent 时代的 Kubernetes，可能更像 HR 加 ERP
几个的时候，人肉还能管。几十个、几百个、几千个同时跑，问题就变了。
云时代，Docker 解决了怎么打包应用，Kubernetes 解决了怎么调度大量容器。Agent 时代也会长出类似的调度系统，但我不太觉得它会只是 Kubernetes 的翻版。
容器通常被设计成可替换、可重启、行为相对确定的运行单元。挂了就换一个副本顶上。
Agent 麻烦得多。它有上下文，有记忆，有工具调用历史，有工作现场，还经常需要人类介入。它挂了，不只是“重启一下”这么简单。你得知道它之前做到哪、为什么停、哪些动作已经产生影响、哪些状态需要恢复。
所以 Agent 时代要长出来的东西，可能更像 HR 系统加 ERP。它要管的不是哪台机器还有空闲算力，而是谁在做什么、归谁负责、花了多少钱、产出值不值、出了问题该找谁。
容器不用像员工一样追踪身份、职责、绩效和成本归属。Agent 要。
这也是 Agent Infra 和传统 Infra 很不一样的地方。
当然，得说句实话：这套基础设施今天还很早期。绝大多数公司连 Session 持久化都做得磕磕绊绊，Agent 成本归属、产出审计、跨团队权限这些事，连标准都还没立起来。今天讲的这些图景，更像是一个正在显形的方向，不是已经摆在那儿的现实。它真正普及的那一天，可能要等到 Agent 出过几次大事故、行业被迫立起规矩之后。
工作本身也会变
回到开头那几个画面。
你打开电脑看 Agent 工作汇报，说明工作正在从"亲自做"变成"派事、审事、兜底"。重要的能力不再只是自己写得快。能同时管几个 Agent，能从它们的产出里挑出问题，能在它们卡住时给出关键判断——这些会越来越像核心技能。
三个人的公司有 47 个 Agent，说明公司规模也会变得不好数。过去看人数，未来可能要看人数、Agent 数、Agent 产能，以及这些 Agent 被组织得怎么样。
HR 来跟 leader 谈 Agent 预算，说明管理者的责任也在变。过去管理是带几个人、定 OKR、做绩效；未来还要加一项：你手下这群 AI 同事干得怎么样，钱花得值不值，出问题谁背锅。新一代能力表里，会冒出来一类很实际的技能：设计 Agent 工作流，调试 Agent 协作，控制 Agent 成本，审计 Agent 决策。
这些不会一夜发生，但地基已经在打了。Session、Sandbox、Event Log、Harness、Runtime，这些词听着冷，落到现实里都是同一件事：软件开始带"员工属性"了，我们得想想怎么把它放进现有的协作系统里。
最后
很多人讨论 AI，喜欢直接跳到"AI 会不会取代人"。这个问题太大，反而容易把眼前的事盖住。
我更愿意问得小一点：如果 AI 开始能和你共事，你打算怎么安排它？
它不是简单替代你，也不只是站在旁边给你打下手。它更像坐到你旁边那个工位上的人——有工号，有权限，有 KPI，有成本中心，也有自己的错误记录。
过去几十年，软件工程主要在做一件事：把人类需求翻译成确定性的代码。从现在开始，软件工程要多做一件事：把不确定的智能，编进确定的组织。
模型决定这些"新员工"脑子有多好。
Harness、Runtime、Agent Infra 决定它们能不能进公司、坐上工位、接任务、交付、复盘、背成本，甚至被淘汰。
这话听着像爆款标题，但我是认真的：未来你的同事，一半可能不是人。
今天讨论的所有 Agent 工程问题，都是在为那一天，提前修办公室、铺电线、装门禁、建档案系统。
