最近用ChatGPT、Codex处理真实项目时，我越来越明显地感觉到一个变化：
Agent正在从“代码库里的工具”，逐渐变成“跨系统执行任务的参与者”。
以前Codex主要做的是：
读代码、改文件、跑测试、分析报错。
但随着Agent能力继续增强，它很可能越来越频繁地接触：
Git仓库、Issue系统、CI/CD、数据库、日志平台、云环境、内部API，甚至部署流程。
这时候一个过去并不突出的工程问题会越来越重要：
这些操作，到底是以谁的身份发生的？
如果Agent一直借用开发者自己的账号、Token、SSH Key去完成所有操作，短期确实方便。
但随着任务越来越多、执行时间越来越长、跨越的系统越来越多，你会开始很难回答：
这次Git修改到底是谁做的？
数据库查询是开发者本人，还是Agent执行的？
哪个Agent触发了CI？
这个Token到底还能访问哪些系统？
任务结束以后，权限有没有回收？
于是Agent时代会出现一个越来越重要的概念：
Machine Identity——机器身份
它可能像CI、日志、权限控制一样，逐渐成为AI开发Workflow里的基础设施。
一、一个真实场景：Agent借着你的身份一路往下执行
假设你让Codex排查一个线上Bug。
最开始，它只需要读取代码。
接着发现需要看CI日志。
再往下，需要查看测试环境数据库。
为了验证修复，还需要调用内部API。
最后甚至需要触发一次部署。
如果这些动作全部借用你的个人账号：
Git显示是你修改的。
CI显示是你触发的。
数据库显示是你访问的。
云平台日志里也是你的身份。
但实际上，大量操作是Agent自动完成的。
这时候就出现了第一个问题：
系统记录的“身份”，和真正的“执行主体”开始分离。
过去我们默认：
账号是谁，操作就是谁做的。
但Agent开始自动跨系统执行以后，这个前提越来越不成立。
二、为什么以前这个问题没那么明显？
因为传统自动化通常比较固定。
比如：
CI只负责构建和测试。
部署系统只负责部署。
监控系统只负责采集数据。
每套自动化都有相对固定的Service Account和权限范围。
但Agent不一样。
它更像一个通用执行主体。
今天修Bug。
明天升级依赖。
后天处理Issue。
以后甚至可以自己：
看日志 → 找根因 → 改代码 → 跑测试 → 触发CI → 验证结果。
也就是说：
同一个Agent Workflow可能横跨多个系统。
这时候真正的问题不再只是：
“它有没有权限？”
而是：
它以什么身份使用这些权限？
三、身份和权限，不是一回事
昨天讲权限边界时，核心问题是：
Agent能做什么？
机器身份回答的则是：
到底是谁在做？
比如一个Agent拥有数据库只读权限。
“只读”是权限。
这个权限属于开发者本人，还是一个专门的Agent Service Account，是身份。
这两个区别非常大。
如果直接使用人的账号，Agent可能会顺带继承：
仓库写权限。
云平台权限。
其他数据库权限。
甚至生产环境能力。
而当前任务可能只需要：
读一个仓库。
写一个Worktree。
跑一次测试。
所以真正成熟的Agent系统应该形成一条链：
Task → Identity → Permission
先确定它在做什么任务。
再给它对应机器身份。
身份决定它能访问哪些资源。
四、为什么直接借用开发者账号越来越不合适？
因为人类账号通常拥有的是：
这个开发者日常工作需要的整套权限。
但Agent执行的是：
当前任务需要的那一小部分操作。
两者范围往往并不一致。
例如一个开发者可能同时拥有：
多个Git仓库。
测试数据库。
CI。
云平台。
内部API。
但一个“修单元测试”的Agent任务，真正需要的可能只有：
仓库读写 + 本地Shell。
如果仍然把整个人类身份交给Agent：
它天然就拥有了很多完全不需要的能力。
这就是机器身份真正重要的原因之一：
身份隔离，是最小权限真正落地的基础。
五、多Agent以后，共享人类身份的问题会被进一步放大
假设未来一个开发者同时管理5个Agent：
Agent A处理前端。
Agent B处理数据库。
Agent C跑测试。
Agent D做Review。
Agent E分析日志。
如果这5个Agent全部借用同一个人的Token和账号：
所有行为最终都归到同一个身份下。
出了问题以后，你很难判断：
到底是哪一个Agent访问了数据库？
谁修改了某个配置？
哪个任务触发了CI？
更重要的是：
Agent A本来只应该处理前端，但因为共享身份，也可能天然拥有数据库权限。
所以Agent规模越大：
独立身份的价值越明显。
六、机器身份真正带来的三个核心价值
1. 可追踪
如果不同Agent拥有独立身份，审计日志可以直接告诉你：
哪个Agent。
因为哪个任务。
在什么时间。
访问了什么资源。
执行了什么动作。
出了问题以后，不需要再猜：
“是不是我的账号被某个自动化用了？”
2. 可撤销
如果Agent借用开发者长期Token：
一旦Token需要撤销，会影响开发者自己的全部工作。
但机器身份可以单独：
创建、轮换、过期、撤销。
某个Agent失效，不需要影响人。
3. 可限制
Review Agent可以只有代码读权限。
测试Agent可以拥有Worktree写权限和测试命令。
Deploy Agent才拥有受控部署能力。
这样不同Agent不会天然继承“万能账号”。
这其实是在控制：
一个错误Agent最多能影响多大范围。
七、为什么短生命周期凭证特别适合Agent？
Agent任务天然具有临时性。
比如：
修一个Bug。
分析一次故障。
完成一次Migration。
处理一个Issue。
任务完成以后，大多数权限其实没有必要继续存在。
所以相比长期Token，更理想的方式是：
任务开始时获得短期凭证，任务结束后自动失效。
比如：
这个任务预计运行30分钟。
那凭证也只需要在对应时间窗口有效。
这样即使凭证发生泄露，它的风险窗口也更小。
更重要的是：
Agent身份的生命周期，可以和任务生命周期保持一致。
八、机器身份为什么还会影响团队级Agent建设？
如果Agent长期绑定某个开发者账号：
这个开发者一旦：
离职。
岗位变化。
权限调整。
Token失效。
Agent Workflow可能也会一起出问题。
但如果一个Agent已经成为团队基础设施，它就不应该依赖某个具体的人长期存在。
所以未来Agent会越来越从：
个人自动化
走向：
组织级机器身份。
比如：
codex-review-project-a
codex-test-project-a
codex-deploy-staging
这些身份属于：
项目、团队、Workflow。
而不是某一个具体开发者。
九、为什么机器身份最终会和审计、可观测性连在一起？
因为Agent跨系统执行以后，真正成熟的系统至少要回答三个问题：
第一，它是谁？
机器身份。
第二，它能做什么？
权限边界。
第三，它实际做了什么？
日志、审计、Tracing。
这三个其实是一整套基础设施。
如果只有权限，没有身份：
你不知道是谁在使用权限。
如果只有身份，没有审计：
你知道是谁，但不知道它做过什么。
如果只有日志，没有独立身份：
最后所有行为仍然显示成同一个开发者。
所以Machine Identity其实处在整套Agent治理体系的中间。
十、给自己测一个指标：机器身份覆盖率
这篇我建议只看一个核心指标：
Machine Identity Coverage Rate——机器身份覆盖率
统计Agent在真实开发过程中会访问的关键系统。
比如：
Git仓库。
CI。
Issue系统。
日志平台。
数据库。
云环境。
内部API。
部署系统。
假设一共10类关键系统。
其中只有4类已经使用：
独立Service Account。
短期Token。
专用机器身份。
其余6类仍然借用：
个人账号。
个人Token。
个人SSH Key。
那么：
机器身份覆盖率 = 40%。
十一、怎么理解这个指标？
低于30%
说明Agent仍然高度依赖个人身份。
常见风险包括：
权限过大。
审计困难。
Token生命周期太长。
个人账号变化影响自动化。
这时候不适合继续无限扩大Agent自主范围。
30%—70%
说明机器身份体系已经开始建立。
这个阶段不用一次全部改完。
应该优先处理高风险系统：
数据库。
CI/CD。
云环境。
部署系统。
生产日志。
机器身份建设应该优先跟风险走。
长期超过70%
说明大多数关键系统已经能够做到：
Agent身份独立。
权限单独授权。
操作可以审计。
凭证能够撤销。
这时候Agent跨系统执行才真正具备规模化基础。
十二、怎么提高机器身份覆盖率？
可以从四件事开始。
第一，高风险系统先停止共享个人Token
尤其是：
数据库、云平台、CI/CD、部署环境。
第二，不同Agent职责不要共用同一个万能Bot
Review、Test、Deploy最好拥有不同身份。
因为它们的风险和权限需求完全不同。
第三，尽量使用短生命周期凭证
任务结束，Credential也结束。
减少长期Secret。
第四，让所有关键动作都能关联到Task ID
最终形成：
Agent → Task → Identity → Action
这样以后排查问题时，可以完整回溯：
为什么执行。
谁执行。
用了什么权限。
造成什么结果。
十三、Plus和Pro怎么判断？
如果你的机器身份覆盖率还很低：
Agent大量跨系统操作仍然依赖：
开发者账号。
个人Token。
共享SSH Key。
长期Credential。
那么当前真正限制Agent进一步扩大的，并不是AI容量。
而是：
身份基础设施还没有成熟。
这种阶段Plus通常已经足够。
更值得先完善：
Service Account。
短期凭证。
身份隔离。
最小权限。
审计。
否则即使增加更多AI容量：
也只是让更多Agent任务通过同一个人的身份同时工作。
风险和混乱都会一起增加。
如果你的机器身份覆盖率已经比较高：
Agent跨Git、CI、数据库、云环境执行时：
身份独立。
权限可控。
操作可审计。
凭证可撤销。
任务与身份之间也有明确关系。
同时又长期存在：
大量成熟Agent任务排队。
多个自动化Workflow持续等待。
AI侧容量真正成为吞吐瓶颈。
这时候Pro才更容易放大生产力。
因为增加的是：
已经具备独立身份和清晰责任边界的Agent产能。
而不是更多借着个人账号执行的自动化任务。
所以判断顺序应该是：
先解决Agent是谁，再讨论让多少Agent同时工作。
十四、未来开发者管理的，可能是一群“机器同事”
这是这个趋势最值得注意的一点。
未来一个团队里长期存在的，可能不仅有：
前端。
后端。
测试。
运维。
还可能有：
Coding Agent。
Review Agent。
Testing Agent。
Incident Agent。
Deployment Agent。
如果这些Agent长期参与真实项目，它们自然也需要：
身份。
权限。
审计。
凭证生命周期。
于是Service Account不再只是传统DevOps概念。
而会逐渐成为：
Agent组织结构的一部分。
最后
ChatGPT、Codex越来越能跨系统执行以后，开发者真正要回答的问题会从：
“AI能不能做这件事？”
逐渐变成：
“到底是谁在做这件事？”
如果Agent可以：
修改Git。
访问数据库。
触发CI。
读取日志。
操作云环境。
甚至参与部署。
却始终借用开发者自己的身份：
短期很方便。
长期却很难规模化。
因为：
身份不清。
权限容易过宽。
审计混乱。
凭证难管理。
真正成熟的Agent Workflow应该让Agent拥有：
属于自己的机器身份。
只拥有必要权限。
只在需要的时间存在。
每个关键操作都能被追踪。
任务结束以后，能力也能够被收回。
当这一套机制真正建立以后，Agent才不再只是：
借着开发者账号执行任务的自动化工具。
而开始真正成为：
可以被团队管理、授权和审计的工程执行主体。
持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。
