一个生产事件，怎样被 Agent 组织真正“看见”？
> TapNow 招聘｜ Agent 平台工程师（ SRE 方向）｜深圳
不久前，我们遇到过一个很典型的问题。
一个超高分辨率视频任务消耗了远超预期的资源，worker 失败后，任务又被队列重新投递。表面上看，它只是某个节点在不断报错；真正的问题却横跨任务设计、资源调度、重试策略、运行时状态和用户影响。
有经验的工程师会把这些碎片接起来：记得刚刚发生过什么，知道该去哪里补证据，也能意识到一条单独的告警没有讲出完整故事。
但 Agent 不会自然拥有这些“余光”。
解决完具体故障以后，我们更想回答的是：如果下一次首先抵达现场的是 Agent ，它怎样知道发生了什么？怎样区分症状与原因？怎样获得足够的权限行动，又不会因为执行得太快而放大风险？
我们在寻找一位工程师，和我们一起把答案做成平台。
## 这不是一个告警数量的问题
Agent 不会顺便扫一眼大盘，不会无意中听到同事谈论上游波动，也不会自动把刚完成的发布和突然出现的 5xx 联系起来。它知道的一切，都必须被系统明确提供。
所以，我们所说的“信号”并不等于再发一条通知。
一个完整的生产信号需要说明：发生了什么事实，它与哪些对象有关，谁应该关注，谁负有行动责任，当前处于什么阶段，最终是被处理、忽略还是升级。对人而言，它可能是一条提醒；对诊断 Agent 而言，它可能是一项工作；即使系统决定不投递，也应该留下可追溯的裁决。
这也是为什么我们把 SRE 看作 Agent 组织的平台角色，而不只是基础设施的维护者。
## TapNow 提供的是一块足够真实的试验场
TapNow 正在构建 Creative OS ，让用户带着想法而来，带着完整作品离开。Agent 贯穿创作全过程，把人的意图逐步转化为策略、任务、图像、视频和粗剪成片；画布、节点、3D 节点与 Playlist ，是人和 Agent 共同工作的 Workspace 。
它背后不是一个封闭的 Demo 环境，而是一套服务全球用户的生产系统：多云、托管服务、serverless 、异步生成任务、模型供应商、边缘网络和持续发布相互交织。
在这里，一次负载均衡异常可能同时表现为健康检查抖动、upstream timeout 和 5xx ；一个认证接口的响应差异，也可能被自动化攻击放大成安全事件。生产链路足够长、变化足够快，靠少数人记住一切既不现实，也不应该成为组织长期运行的方式。
## 我们正在搭一条“知—觉—行”的神经回路
“知”，是让 Agent 获得可靠的生产 context：系统拓扑、依赖关系、发布契约、历史事故、权限边界和当前事实。
“觉”，是让它知道此刻应该注意什么：指标、日志、trace 、发布和平台事件如何形成有语义的信号，而不是一片通知噪声。
“行”，是把诊断、变更、回滚和恢复放进明确的授权与安全闸门中，并留下证据、结果和反馈。
我们已经在把 CI/CD 和平台事件从散落的通知，整理成拥有生命周期、路由、权限和投递结果的信号。接下来的工作，是让这条回路继续进入可观测性、发布、事故响应和日常生产操作，并在真实环境中不断校准。
## 你会从真实生产出发，而不是从一张架构图出发
你仍然会写 Shell 、Python 、Terraform ，排查 DNS/TLS 、LB/CDN 、数据库、缓存、队列、GKE 和 serverless ，也会参与发布和真实事故。
但“问题恢复了”只代表第一层工作完成。接下来还要继续追问：
- 哪些信号本该更早出现，哪些通知其实只是噪声？
- 刚才的判断依赖了哪些隐性知识，怎样把它变成 Agent 可使用的 context ？
- 哪些步骤可以先由 Agent 完成只读调查，哪些动作能够最小写入、随时回滚并做 postcheck ？
- 这次失败应该留下怎样的 eval ，才能证明系统下一次真的做得更好？
最终的产物可能是一条新的信号路由、一份可执行的变更契约、一个故障签名、一组权限护栏，或者一套基于真实事故的评测。脚本和 runbook 都会存在，但它们只是能力的载体。
## 我们会用一些很具体的事实判断彼此是否合适
你需要在公有云的托管服务或 serverless 架构上扛过真实流量，并且能够对跨领域的生产问题独立闭环。只熟悉自建机房、自建 Kubernetes 或私有化交付，很难直接覆盖 TapNow 当前的生产形态。
你也需要真正深度使用 Agent 。不是让它偶尔补几行 YAML ，而是已经用 Coding Agent 完成过复杂、跨步骤、涉及真实系统的工作。做过 harness 、tool use 、memory 、multi-agent 、failure recovery 或 eval ，会帮助你更快进入这里的工作。
我们同样在意你的生产习惯：默认先只读、最小 diff 、可回滚、做 postcheck ；能把判断写成结论、证据和风险；愿意把一次个人经验提炼为组织可以复用的机制。
你的 title 可以是 SRE ，也可以来自后端、平台、DevOps 或基础设施。我们不机械看工龄和工具清单，但会认真验证三件事：你是否真正处理过复杂生产问题，是否理解 Agent 的能力边界，以及是否能把二者连接成长期运行的平台。
如果你最享受的是依靠个人经验反复救火，或者认为装好 Terraform 、Kubernetes 和告警规则就已经完成工作，这里大概不会适合你。我们更希望系统能够记住经验，让英雄主义逐步变得不再必要。
## 如果这件事让你兴奋
工作地点在深圳。请将简历、GitHub 、个人项目或其他能够证明你的材料发至 **builders@tapnow.ai** ，邮件标题注明：**Agent Platform Engineer + 姓名**。
比简历更有帮助的是一份可验证的证据：一个仍在运行的项目、一篇公开事故复盘、一个合入开源项目的 PR ，或者你自己的 harness 、skill 、eval 仓库。
来信时，也请简单回答三个问题：
1. 选一个你真正独立闭环过的生产问题：最初的表象是什么，哪个证据改变了你的判断？
2. 如果把其中一部分工作交给 Agent ，你会先交出哪一步，又会保留哪一道人工边界？
3. 面对一个陌生的生产系统，你会如何判断它最先缺少的是 context 、signal ，还是安全的 action ？
我们不是在寻找下一位替团队守夜的人。我们想一起建设的，是一套即使人没有一直盯着，组织也依然能够感知、判断、行动并从结果中学习的生产系统。
---
原文链接：[点击查看](https://www.v2ex.com/t/1236485)
不久前，我们遇到过一个很典型的问题。
一个超高分辨率视频任务消耗了远超预期的资源，worker 失败后，任务又被队列重新投递。表面上看，它只是某个节点在不断报错；真正的问题却横跨任务设计、资源调度、重试策略、运行时状态和用户影响。
有经验的工程师会把这些碎片接起来：记得刚刚发生过什么，知道该去哪里补证据，也能意识到一条单独的告警没有讲出完整故事。
但 Agent 不会自然拥有这些“余光”。
解决完具体故障以后，我们更想回答的是：如果下一次首先抵达现场的是 Agent ，它怎样知道发生了什么？怎样区分症状与原因？怎样获得足够的权限行动，又不会因为执行得太快而放大风险？
我们在寻找一位工程师，和我们一起把答案做成平台。
## 这不是一个告警数量的问题
Agent 不会顺便扫一眼大盘，不会无意中听到同事谈论上游波动，也不会自动把刚完成的发布和突然出现的 5xx 联系起来。它知道的一切，都必须被系统明确提供。
所以，我们所说的“信号”并不等于再发一条通知。
一个完整的生产信号需要说明：发生了什么事实，它与哪些对象有关，谁应该关注，谁负有行动责任，当前处于什么阶段，最终是被处理、忽略还是升级。对人而言，它可能是一条提醒；对诊断 Agent 而言，它可能是一项工作；即使系统决定不投递，也应该留下可追溯的裁决。
这也是为什么我们把 SRE 看作 Agent 组织的平台角色，而不只是基础设施的维护者。
## TapNow 提供的是一块足够真实的试验场
TapNow 正在构建 Creative OS ，让用户带着想法而来，带着完整作品离开。Agent 贯穿创作全过程，把人的意图逐步转化为策略、任务、图像、视频和粗剪成片；画布、节点、3D 节点与 Playlist ，是人和 Agent 共同工作的 Workspace 。
它背后不是一个封闭的 Demo 环境，而是一套服务全球用户的生产系统：多云、托管服务、serverless 、异步生成任务、模型供应商、边缘网络和持续发布相互交织。
在这里，一次负载均衡异常可能同时表现为健康检查抖动、upstream timeout 和 5xx ；一个认证接口的响应差异，也可能被自动化攻击放大成安全事件。生产链路足够长、变化足够快，靠少数人记住一切既不现实，也不应该成为组织长期运行的方式。
## 我们正在搭一条“知—觉—行”的神经回路
“知”，是让 Agent 获得可靠的生产 context：系统拓扑、依赖关系、发布契约、历史事故、权限边界和当前事实。
“觉”，是让它知道此刻应该注意什么：指标、日志、trace 、发布和平台事件如何形成有语义的信号，而不是一片通知噪声。
“行”，是把诊断、变更、回滚和恢复放进明确的授权与安全闸门中，并留下证据、结果和反馈。
我们已经在把 CI/CD 和平台事件从散落的通知，整理成拥有生命周期、路由、权限和投递结果的信号。接下来的工作，是让这条回路继续进入可观测性、发布、事故响应和日常生产操作，并在真实环境中不断校准。
## 你会从真实生产出发，而不是从一张架构图出发
你仍然会写 Shell 、Python 、Terraform ，排查 DNS/TLS 、LB/CDN 、数据库、缓存、队列、GKE 和 serverless ，也会参与发布和真实事故。
但“问题恢复了”只代表第一层工作完成。接下来还要继续追问：
- 哪些信号本该更早出现，哪些通知其实只是噪声？
- 刚才的判断依赖了哪些隐性知识，怎样把它变成 Agent 可使用的 context ？
- 哪些步骤可以先由 Agent 完成只读调查，哪些动作能够最小写入、随时回滚并做 postcheck ？
- 这次失败应该留下怎样的 eval ，才能证明系统下一次真的做得更好？
最终的产物可能是一条新的信号路由、一份可执行的变更契约、一个故障签名、一组权限护栏，或者一套基于真实事故的评测。脚本和 runbook 都会存在，但它们只是能力的载体。
## 我们会用一些很具体的事实判断彼此是否合适
你需要在公有云的托管服务或 serverless 架构上扛过真实流量，并且能够对跨领域的生产问题独立闭环。只熟悉自建机房、自建 Kubernetes 或私有化交付，很难直接覆盖 TapNow 当前的生产形态。
你也需要真正深度使用 Agent 。不是让它偶尔补几行 YAML ，而是已经用 Coding Agent 完成过复杂、跨步骤、涉及真实系统的工作。做过 harness 、tool use 、memory 、multi-agent 、failure recovery 或 eval ，会帮助你更快进入这里的工作。
我们同样在意你的生产习惯：默认先只读、最小 diff 、可回滚、做 postcheck ；能把判断写成结论、证据和风险；愿意把一次个人经验提炼为组织可以复用的机制。
你的 title 可以是 SRE ，也可以来自后端、平台、DevOps 或基础设施。我们不机械看工龄和工具清单，但会认真验证三件事：你是否真正处理过复杂生产问题，是否理解 Agent 的能力边界，以及是否能把二者连接成长期运行的平台。
如果你最享受的是依靠个人经验反复救火，或者认为装好 Terraform 、Kubernetes 和告警规则就已经完成工作，这里大概不会适合你。我们更希望系统能够记住经验，让英雄主义逐步变得不再必要。
## 如果这件事让你兴奋
工作地点在深圳。请将简历、GitHub 、个人项目或其他能够证明你的材料发至 **builders@tapnow.ai** ，邮件标题注明：**Agent Platform Engineer + 姓名**。
比简历更有帮助的是一份可验证的证据：一个仍在运行的项目、一篇公开事故复盘、一个合入开源项目的 PR ，或者你自己的 harness 、skill 、eval 仓库。
来信时，也请简单回答三个问题：
1. 选一个你真正独立闭环过的生产问题：最初的表象是什么，哪个证据改变了你的判断？
2. 如果把其中一部分工作交给 Agent ，你会先交出哪一步，又会保留哪一道人工边界？
3. 面对一个陌生的生产系统，你会如何判断它最先缺少的是 context 、signal ，还是安全的 action ？
我们不是在寻找下一位替团队守夜的人。我们想一起建设的，是一套即使人没有一直盯着，组织也依然能够感知、判断、行动并从结果中学习的生产系统。
---
原文链接：[点击查看](https://www.v2ex.com/t/1236485)
评论
暂无评论。