Tara Seshan：“a persistent coworker”
Tara Seshan：一个会长期留在项目里、和你一起把事情做完的AI同事。
Tara Seshan把AI产品分成了三个阶段。
第一个阶段是聊天。人问一句，模型答一句。
第二个阶段是Agent。人交代一项任务，它调用工具，跑一段时间，交回一个结果。
她正在思考第三个阶段：AI不再每次等你重新说明项目，而是留在工作环境里，记得目标和进度，持续推进任务。
备注：Tara现在负责OpenAI的Codex与ChatGPT Work产品。
在Lenny's Podcast的访谈中，Tara谈了一个很实际的问题：如果Agent真要像同事一样干活，开发者就得给它补上同事工作时依赖的那套东西。
它要能拿到正确的文件和数据，知道自己能动哪些系统，记住做到了哪一步，也要让人看得见它为什么这样做。
以下为访谈内容，我们进行了翻译与整理。
Tara谈从聊天、Agent到常驻AI同事
AI同事不是一个更大的聊天框
聊天式产品很容易理解：给它一段上下文，拿回一次回答。Agent已经向前走了一步，它可以读取文件、调用工具、在云端运行一会儿。
Tara所说的常驻协作者还要多做一件事：保持工作状态。
今天你让它检查一次发布，明天继续时，它不应该把代码库、变更范围和上次失败的原因全忘了。一周后回到同一项目，它应该知道什么已经做完，哪个判断是人类做的，下一步该从哪里开始。
这不只需要更长的上下文窗口。项目状态要能够被写入、更新和追溯，模型需要区分已确认的事实、待验证的推测和过时的记忆。这已经不是聊天记录该保存多久的问题，而是一个长期运行系统怎样管理状态。
一个人盯一个Agent，也会成为新的瓶颈
Tara Seshan：“steering than rowing”
Tara Seshan：未来的工作更像掌舵，而不是每一下都由人划。
Tara用了一个很容易记住的比喻。Agent承担划船的动作，人决定船往哪里走。
这种变化已经出现在编程工具里。
开发者以前指导的是一行代码，现在可以交给Agent一个Bug、一次依赖升级，甚至一个小功能。指令所在的层级在上升，人要做的是给目标、设边界、核对结果。
Agent干活，人负责方向
但如果每个人都私下跑几个Agent，团队很快会遇到另一个问题：人们看不见彼此的Agent正在做什么。重复修一个问题、同时改到同一个文件、两边使用了不同的前提，都可能在合并时才被发现。
Tara希望工作最终像多人游戏：几个人共同掌握一组Agent，能看见彼此的任务和进度，也能在Agent之间交接上下文。
这时候，产品需要的就不是同时开十个窗口。它要有任务队列、冲突检测、状态同步和人工接管点。否则Agent越多，人只会被更多通知和合并冲突包围。
把Agent关在没有数据的房间里，它当不了同事
Tara Seshan：“cloud infrastructure”
Tara Seshan：让Agent在云端工作，需要补上大量基础设施。
在访谈中，Tara假设了一名新同事：公司把他关在一间房子里，不给Google Docs、Slack和公司数据库的访问权限，然后等他产出结果。这个人再聪明也干不了多少活。
Agent也一样。
Agent的最终效果不只由模型聪明程度决定
让一个代码Agent常驻项目，至少要处理四件事。它能读哪些仓库和文档；能否调用终端、CI和部署系统；谁批准高风险操作；任务失败后怎样撤回。
对企业来说，这些问题往往比提示词更难。同一个Agent在测试环境可以拥有较大权限，到生产环境就应收紧。读代码和删数据不能共用一把钥匙。一个长任务跨越几个小时后，凭证还要能轮换，权限也要能随时收回。
只按今天的模型做产品，两个月后就可能落后
Tara Seshan：“two to three months”
Tara Seshan：做AI产品时，她会看两到三个月后的模型能力。
Tara认为，团队如果只根据模型今天能做什么来设计产品，产品上线时就可能已经落后。但一步跨到一年后也不现实，因为很多关键能力还不能稳定运行。
她给出的窗口是两到三个月。
AI产品需要给近期的模型跃迁留出余量
这个判断对工程架构很实用。
不要把任务拆分、模型选择、工具调用和验收规则全写死在一个巨大流程里。将这些环节留成独立接口，模型升级后，团队可以只替换路由或调整人工检查点。
更简单的做法是，把目前模型经常做错、但近几个版本正在快速改善的步骤，保留成可替换模块。不用为了弥补今天的一次错误，造出一套三个月后就没人需要的复杂规则。
代码能用测试验收，知识工作不行
Tara Seshan：“via tests”
Tara Seshan：编程任务很特殊，结果往往可以通过测试来验证。
Tara在做ChatGPT Work时发现，代码Agent和知识工作Agent不能共用同一套交互思路。
修一个Bug，测试过没过是一个清楚的信号。生成一份销售分析，页面上的数字看起来很完整，人也不能直接相信。需要知道它读了哪些数据，排除了什么，缺失值怎样处理，又是怎样得到结论的。
代码有测试，知识工作还要核对过程
Tara Seshan：“in-progress work”
Tara Seshan：人需要看见AI正在做的工作，也要看得到来源和输入。
这会直接改变Agent产品的界面。一个进度条只能告诉你任务还没完成，不能告诉你它是否读错了表、漏了一个文件，或者在一个错误假设上跑了半个小时。
开发者需要的是可检查的执行轨迹：输入来源、工具调用、中间产物、关键判断和失败位置。人可以中途改变方向，也可以在交付后回放整个过程。
周报可以交给AI，把问题想明白这件事不要
Tara Seshan：“writing as reporting”
Tara Seshan：一类写作只是汇报，比如整理团队本周进展。
Tara Seshan：“writing as thinking”
Tara Seshan：另一类写作是思考，比如弄清楚为什么要做一个产品、为什么选这条路线。
Tara愿意把汇报型写作交给模型。收集进展、归纳状态、生成一份发布通知，这些工作有现成的材料，产出也可以校对。
她不愿意自动化的，是那些靠书写过程来理清判断的工作。把零散想法排成结构，删掉站不住的论据，发现两个相互冲突的假设，这个过程本身就是工作。
Tara解释哪些写作可以交给AI
对开发者来说，这条线同样存在。根据已有改动整理发布说明，可以自动化。决定一个服务是否要拆分，事故后怎样改边界，为什么接受某种风险，不应该只因为模型写出了一份漂亮文档就算完成。
开发者要搭的，是数字员工的工作环境
常驻AI同事目前仍然是Tara对下一阶段产品的判断，不是ChatGPT Work已经完整上线的功能清单。不过，她谈到的工程条件已经很具体。
先让Agent有一份可更新的项目状态，而不是每次把全部历史塞回提示词。
再把权限按资源和动作分开。读文档、改代码、执行部署、访问生产数据，不能默认被视为同一级操作。
执行过程中保留来源、工具记录和中间产物。人看不懂Agent正在做什么，就无法在正确的时候介入。
最后给高风险步骤设人工检查点，并提前准备回滚路径。一个真能干活的Agent必然会接触更多系统，出错时的影响也会比聊错一句大得多。
Tara所说的第三个时代，真正难的部分不在“同事”这个名字。
聊天产品做错了，用户关掉窗口重来。一个常驻项目的Agent做错了，可能已经改了文件、调了外部系统，还把错误状态留给了下一次任务。
所以，它能不能像同事一样稳定干活，最后要看的是一套很熟悉的工程能力：状态管理、最小权限、全链路日志、可执行的验收条件和可靠回滚。
参考链接：
——好文链接——
AI时代的工作要靠自己创造！斯坦福AI经济学家：下一代开发者，要学会给一群Agent找事做，更大的机会是复制高手的工作方法
吴恩达谈程序员的新分水岭：AI会写代码了，优秀工程师反而比以前更忙。还按2022年方式工作的人，已经危险了
AI开始比初级员工便宜！比尔·盖茨发出警告：AI已经到了“临界点”，这一次，技术进步真的会减少工作
