8.0
热点
AI SCORE
编程提效2026-09-29 13:55
AI作为团队成员：分配、治理与审查实践指南
dev.to · AI#AI Agent#工作流#团队协作
Editor brief · 编辑速览
探讨如何向AI代理分配任务、提供上下文、明确责任归属、审查输出和处理卡死问题。
当 AI 智能体能够完成的不只是回答一个提示词时，它们会变得更有用。
与其请求 AI 解释一个问题或生成几行代码，我们现在可以给一个智能体分配一项工作，让它调查问题、做出修改、运行测试并汇报结果。
这改变了人与 AI 的关系。
AI 智能体不一定是在取代某个人。它正在成为团队执行工作的一种新方式。
这就是智能体队友（Agentic Teammates）概念的由来。
但一旦智能体开始表现得像一个队友，团队需要考虑的就不仅仅是底层模型的质量了。
这些问题正变得与 AI 智能体本身一样重要。
智能体队友是一个参与团队工作流程的 AI 智能体，它承担定义明确的工作片段，而不仅仅是响应单个提示词。
这个区别很重要。
聊天机器人可以帮助你思考一个问题。智能体队友则可以迈出下一步。
例如，开发者可以创建一个任务来调查一个失败的 API 端点。智能体可以检查相关代码、识别问题、做出修改、运行测试并返回调查结果。
开发者仍然对结果负责。
智能体负责部分执行工作。
这创造了一种有用的责任分工：
具体的平衡取决于任务，但重要的是智能体成为了现有工作流程的一部分，而不是作为一个孤立的 AI 对话存在。
传统 AI 辅助与智能体工作之间最大的区别之一是，提示词不一定够用。
如果你只是向 AI 提一个简单的问题，一个提示词可能包含了它需要的一切。
但一个真正的任务是不同的。
一个真正的任务通常需要：
没有这些上下文，智能体就必须做出假设。
当智能体被允许实际做出修改时，这些假设的代价会变得更高。
这就是为什么智能体工作流程受益于将持久性指令与任务特定需求分开。
持久性指令可以解释智能体通常如何工作。
任务说明这次需要发生什么。
这样可以让工作流程更容易重复，而不会把每个任务都变成一个巨大的提示词。
我不认为每个智能体都需要是一个能做任何事的通用 AI。
事实上，专业化的智能体可以让智能体工作流程更容易管理。
考虑一个软件团队有几种 recurring 类型的工作。
一个智能体可以专注于后端开发。另一个可以处理测试。还有一个可以帮助撰写文档。另一个可能围绕研究或分析进行配置。
关键不是每个智能体都必须局限在一个狭窄的任务上。
关键的是团队应该知道一个智能体被配置来做什么。
这使分配工作变得更加有目的性。
哪个 AI 应该打开来处理这项工作？
问题变成了：
哪种能力应该处理这项工作？
这是一个重要的转变，因为它使智能体变得可复用。
团队不需要在每次有人需要某种类型的工作时都重新创建相同的指令。
给智能体执行责任并不意味着给它结果的所有权。
这个区别很重要。
假设一个开发者负责修复一个 bug。他们分配一个智能体来调查问题并实现更改。
智能体可能做了大部分的实际工作。
但开发者仍然是负责决定结果是否正确、是否可以继续推进的人。
这创造了两个独立的概念：
它们不一定是同一方。
随着智能体能够独立工作更长的时间，这种分离变得尤为重要。
如果没有人负责审查结果，自主性很快就会变成一种负担。
对于每个任务来说，并没有一个正确的自主权级别。
一个有用的思考方式是考虑犯错的后果。
一个研究可能解决方案的智能体通常可以更自由地运作，而不是一个更改影响生产基础设施的智能体。
同样，一个准备文档的智能体可能需要的监督少于修改认证逻辑的智能体。
所以不要问：
AI 应该自主吗？
而是问：
这项任务的哪些部分智能体可以在不干预的情况下安全处理？
这可以引向一个实际的分工。
智能体可能被允许：
而人类仍然负责：
目标不是最大化的自主权。
目标是适当的自主权。
这是智能体工作流程可能变得困难的地方。
假设一个智能体在一个私人的 AI 会话中花了一个小时调查一个问题。
它发现了一些重要的东西。
它做了几次修改。
它遇到了一个阻碍。
然后它最终产生了一个结果。
如果所有这些信息只存在于那个人的会话中，当其他人需要审查工作时会发生什么？
他们必须重建对话。
这不太容易扩展。
为了让智能体队友作为团队的一部分工作，重要的上下文应该保持在工作本身。
任务应该包含目标和需求。
对话应该 capture 决策和后续说明。
执行历史应该显示智能体实际做了什么。
最终结果应该对负责审查的人保持可访问。
这是仅仅使用 AI 智能体和真正构建智能体工作流程之间最大的区别之一。
智能体说"已完成"并不等同于任务已完成。
审查过程应该关注实际结果。
根据任务的不同，这可能意味着检查：
对于编码任务，这可能涉及审查 diff 和测试结果。
对于研究，可能意味着检查来源和结论。
对于文档，可能意味着检查技术准确性和完整性。
因此，审查过程应该与原始任务相关联，而不是被视为一个完全独立的活动。
这给了审查者回答一个简单问题所需的上下文：
智能体是否真的完成了我们要求它做的事情？
智能体队友仍然会遇到困难。
问题可能是缺少上下文。
需求可能是模糊的。
某个依赖可能不可用。
智能体可能到达了一个需要领域知识的人来做决定的节点。
这不一定意味着智能体失败了。
这意味着工作流程需要一个让人类干预的方式。
智能体工作 → 智能体遇到阻碍 → 人类提供上下文 → 智能体继续
重要的一点是，干预应该发生在同一件工作中。
你不希望开发者打开另一个聊天，再次解释整个情况，手动重建智能体已经知道的一切。
智能体应该能够接收额外的上下文并从那里继续。
这更接近于与人类队友协作的方式。
这也改变了我们对评论（comments）的思考方式。
在传统的项目管理系统中，评论往往只是围绕任务的讨论。
而在 AI 智能体队友的模式下，评论可以成为执行循环的一部分。
人可能会告诉智能体：
使用现有的身份验证中间件，而不是引入新的依赖项。
智能体随后可以带着这条额外指令继续工作。
或者，评审者可能会说：
测试通过了，但错误处理不符合现有的服务模式。请修改。
重要的是，指令始终与工作本身保持关联。
这样就形成了一个有用的反馈循环，而无需团队在任务跟踪器和独立的 AI 对话之间来回切换。
当一个智能体不够用时
有些任务足够简单，一个智能体就能完成。
有些任务则天然涉及多个角色。
想象一下开发一个新功能：
一个智能体可能负责调研现有实现。
另一个可能负责后端开发。
再一个可能负责编写测试。
还有一个可能负责审核文档。
你可以手动协调所有这些，但协调本身最终也会变成一项工作。
这正是智能体团队（agent teams）或智能体群（groups）变得有用的地方。
一个协调型智能体可以解读整体目标，并在需要不同能力时调用其他智能体。
人类团队仍然参与其中，但协调可以在工作流内部进行，而不是通过一堆互不关联的 AI 会话来进行。
重要的原则是：多个智能体不应该简单地等同于多个独立的对话。
整个工作需要一个共享的上下文。
Sharkly.AI 在这个模型中的位置
这种做法的一个实际例子是 Sharkly。
Sharkly 将智能体（Agents）视为保存的工作配置，而非一次性提示（one-off prompts）。一个智能体可以包含指令、技能（Skills）、运行时（Runtime）、代码库、环境设置和运行设置，然后像队友一样被分配到任务（Task）。人保持负责，而智能体处理执行。
有趣的地方在于智能体周围发生的一切。
一个 Sharkly 任务可以包含目标、范围、验收标准、责任人、执行分配人、评论、状态和历史。人可以作为人类分配人保持负责，而由智能体或团队（Crew）处理执行。
这直接体现了"责任"与"执行"的分离。
这也意味着工作不必消失在一个私密的 AI 会话中。
智能体的对话、执行、评论和结果都可以与任务保持关联。当智能体是执行分配人时，一条符合条件的评论可以继续智能体的运行。
使用技能（Skills）实现可复用指令
Sharkly 还将从可复用实践与单独的任务需求中分离出来。
技能可以包含可复用的指令和支持文件，并绑定到应该遵循相同实践的智能体，比如审核规则、交付清单或写作规范。一次性需求可以留在任务上，而不是嵌入到技能中。
对于团队来说，这是一个有用的模式，因为它避免了将每个任务都变成一个全新的提示。
智能体知道自己通常如何工作。
任务说明现在需要发生什么。
使用团队（Crews）处理更复杂的工作
当一个智能体不够用时，Sharkly 还有另一层叫做团队（Crews）。
一个团队由一个领导智能体加上其他智能体和人组成。领导智能体可以解读目标，并在工作需要不同角色或顺序时调用其他智能体成员。
这与智能体队友的理念天然契合。
团队不需要分别考虑每个 AI 会话，而是可以思考哪个能力应该处理工作的哪部分。
对话式聊天与跟踪工作的区别
探索和实际团队工作之间也存在一个重要的区别。
Sharkly 的独立智能体聊天（Agent Chat）旨在用于在工作需要归属之前进行探索、规划或行动。当工作需要共享状态、历史或审核时，它可以变成一个任务。
这种区别在 Sharkly 之外也说得通。
并非每个与 AI 的对话都需要成为一个被跟踪的任务。
但一旦智能体在做其他人依赖的工作，这项工作就需要一个持久的地方来存放。
一个实用的 AI 智能体队友工作流
将所有内容整合起来，一个团队可以像这样构建 AI 智能体工作：
1. 定义结果
从一个清晰的任务开始。
解释需要完成什么、哪些在范围内、哪些不在范围内，以及如何评估结果。
2. 指定人类负责人
确保有人对结果负责。
这个人不需要亲自执行每个步骤。
3. 选择合适的智能体
选择配置与工作类型相匹配的智能体。
专用智能体可能比通用智能体更有用。
4. 给智能体正确的上下文
提供工作所需的代码库、文件、需求、约束条件和其他信息。
不要假设智能体了解项目特定的约定，除非已经提供给它。
5. 让智能体执行
允许它在设定的边界内执行工作。
6. 将沟通与任务保持关联
如果有什么变化，把新信息添加到工作中，而不是开始一个无关的对话。
7. 根据要求审查实际输出
将实际输出与原始需求进行对照检查。
不要把智能体自己的完成消息当作审批。
8. 必要时重新引导
如果工作不正确，解释需要更改什么，并在适当的地方让智能体继续。
由负责人决定工作是否就绪。
这个工作流创建了一个简单的反馈循环：
分配 → 执行 → 审核 → 重新引导 → 接受
智能体可以处理更多的执行工作，而人保持与重要决策的连接。
良好的 AI 智能体团队协作是什么样的
最好的 AI 智能体工作流可能不会看起来像是人类消失了一群自主智能体接管了一个项目。
它们看起来更像是团队获得了一个新类别的队友。
有些工作仍然完全由人处理。
有些工作会委托给智能体。
有些工作会在人和智能体之间来回切换。
有些更大的任务会涉及多个智能体围绕一个共同目标协调工作。
共同的要求是可见性。
每个人都应该能够理解：
没有这些答案，无论底层模型多么强大，AI 智能体工作流都可能变得难以管理。
与 AI 智能体队友协作的未来
AI 智能体改变的不只是我们使用的工具。
它改变了工作的单位。
多年来，任务就是分配给一个人的东西。人打开工具、执行工作，然后汇报。
现在执行槽位越来越多地在人和智能体之间共享。
这意味着项目管理系统、开发工作流和协作工具需要适应一个新的现实。
一个智能体需要的不仅仅是一个提示。
它需要一个角色、上下文、环境、边界，以及一种报告工作的方式。
一个人需要的不仅仅是通知智能体完成了。
他们需要足够的上下文来审核所发生的事情，并决定接下来应该发生什么。
团队需要一个共享的记录，将所有这些连接在一起。
这就是为什么 AI 智能体队友的概念比单纯说 AI 可以自动化任务更有意义。
真正的问题不只是：
AI 智能体能做什么？
而是我们如何围绕智能体能做的事情构建团队工作流？
与 AI 智能体队友协作需要一种与把 AI 用作助手略有不同的思维方式。
智能体不应该简单地接收一个提示然后消失在一个私密会话中。
它应该有一个明确的角色、足够的上下文来执行工作，以及围绕它能做什么的适当边界。
团队应该对结果负责，而智能体处理它有能力处理的执行。
最重要的是，工作应该保持可审核。
这意味着将需求、对话、执行历史、阻碍和结果与工作本身保持连接。
我们仍在摸索人类与智能体长期协作的模式。但有一点已经越来越清晰：从 AI 智能体中获益的团队不仅仅是最拥有最强模型的团队，而是最懂得如何围绕智能体组织工作的团队。