原文：https://dev.to/therealmrmumba/how-humans-and-ai-agents-can-work-together-a-practical-guide-to-agent-based-project-management-36p6（作者 @therealmrmumba）
AI编码Agent改变了我对软件开发的思考方式。
不久前，当我想到在开发中使用AI时，主要考虑的是向模型提问、获取答案、复制一些代码，然后自己继续完成工作。
这种模式正在快速演变。
如今，AI Agent可以被赋予任务，检查代码仓库，修改文件，运行工具，调查错误，并持续工作以达成目标。
但这带来了一个新问题。
当AI不再仅仅是一个助手，而是成为团队的一部分时，会发生什么？
如果一个开发者为一个任务启动了Agent，另一个开发者能否添加上下文？
在Agent工作时，能否有人引导它？
能否让其他人审查结果并继续任务？
工作能否在一个人和一个Agent之间来回交接，而不丢失上下文？
随着开发团队开始让多个AI Agent与人类开发者并肩工作，这些问题正变得越来越重要。
挑战不简单是让一个AI Agent去做工作。
而是要弄清楚人类和Agent如何协作，而不产生另一层脱节的对话、提示、终端和状态更新。
人与Agent协作究竟意味着什么？
我认为“使用AI”和“与AI Agent协作”之间有一个重要的区别。
当我让ChatGPT解释一个API时，那是AI辅助。
当我让一个AI编码工具建议一个函数时，那也是辅助。
但Agent可以以不同的方式运作。
Agent不必等待我提供每一个单独的指令，它可以接收一个更广泛的目标，并执行多个步骤来实现它。
这改变了工作流。
一个开发者可能会创建这样一个任务：
为新的API端点添加身份验证，更新测试，并确保现有端点继续正常工作。
然后，Agent可以检查代码仓库，进行修改，运行测试，并报告发生的情况。
但开发者不一定在这个过程中消失。
他们可能在过程中意识到，身份验证的需求需要以不同的方式工作。
第二个开发者可能注意到一个边界情况。
审查者可能要求额外的测试。
产品经理可能更改验收要求。
Agent需要对这些变化做出响应。
这就是我所指的人与Agent协作。
人类不仅仅是给Agent一个提示然后等待最终结果。
人类和Agent正在参与一项持续进行的工作。
多人能否加入同一个实时AI-Agent会话？
这是围绕基于Agent的开发中最有趣的问题之一。
想象一下，一个开发者启动一个AI Agent来处理一个功能。
Agent完成了实现的一半。
另一个开发者查看这个任务，发现由于系统另一部分的约束，原始方法行不通。
在传统的工作流中，第二个开发者可能会给第一个开发者发消息，然后第一个开发者回到他们的终端，告诉Agent该怎么做。
这是大量不必要的交接。
一个更好的模型是让任务本身成为共享上下文。
与其将Agent会话视为某人的私有对话，团队可以将需求、讨论、执行历史和审查与同一项工作保持关联。
这是Sharkly背后的核心理念之一。
Sharkly将自己描述为一个为人和Agent设计的工作管理系统，将需求、任务状态、讨论、执行记录和审查整合在一起，而不是分散在私有提示和终端会话中。
这并不意味着每个人必须在同一时刻向完全相同的聊天窗口输入内容。
实际上，Sharkly的文档区分了独立的Agent Chat和围绕Task发生的协作。
独立的Agent Chat属于创建该会话的人。基于任务的工作流则不同：Task成为了一个共享记录，人们可以围绕工作进行协作。
这个区别很重要。
目标不一定是“把所有人放进一个巨大的聊天窗口”。
目标是：
让每个人都从同一个事实来源进行工作。
人与 Agent 如何协作
一个现实的工作流程可能看起来像这样：
产品需求 → 人类规划 → Agent 执行 → 人类反馈 → Agent 调整 → 人类评审 → 完成
让我们更具体地看看。
第一步：人类定义任务
一名开发者或产品经理创建一个任务，描述需要完成的工作。
任务可以包含目标、描述、验收标准、优先级、状态等项目信息。
在 Sharkly 中，一个任务还可以有负责人（人）和分配来执行它的 Agent 或 Crew（团队）。
第二步：Agent 开始工作
Agent 接收任务上下文并开始执行。
一个基于任务的运行可以包含任务描述、当前状态、项目和迭代信息、最新的评论、Agent 指令、技能、代码仓库、环境配置以及运行时设置。
这很重要，因为 Agent 并不是仅在一个孤立的指令下工作。
它拥有结构化的工作上下文。
第三步：人类补充上下文
在工作进行中，开发人员可能意识到一些重要信息：
“不要修改旧的认证中间件。移动客户端仍然依赖它。”
这条信息需要成为工作的一部分。
在 Sharkly 中，任务评论正是为这种讨论设计的。评论可以包含新的需求、限制、审查发现、决策、文件、截图或对任务 Agent 负责人的指示。
第四步：Agent 继续工作
这条评论可以为指派到该任务的 Agent 触发一次后续运行。
Sharkly 的执行模型允许符合条件的成员评论将后续工作加入队列，即使在其他运行处于活动状态时也可以。系统可以合并待处理的工作，因此快速的评论不会为同一 Agent 和任务创建重复的待处理运行。
这与每次需求变更都简单地开始一个新的 AI 对话的模式截然不同。
第五步：另一位人类审查结果
Agent 完成了。
现在需要有人来检查结果。
实现正确吗？
测试通过了吗？
Agent 是否误解了需求？
有什么需要修改的地方吗？
Agent 可以将结果作为与执行记录关联的任务评论留下，而执行日志提供了有关本次运行的额外信息。
人类由此成为审查者，而不仅仅是等待 AI 输出的人。
为什么上下文正在变成一个项目管理问题
这可能是 AI Agent 为开发工作流带来的最大变化。
我们一直需要项目管理，因为软件开发涉及多人、任务、依赖关系、优先级和决策。
Agent 带来了另一个问题：
上下文连续性。
一个 AI Agent 可以完成出色的工作但仍然失败，因为它没有正确的上下文。
可能需求变了。
可能另一位开发者做出了相关的架构决策。
可能发现了一个边缘案例。
可能之前的尝试失败了。
如果这些信息只存在于某人的私人聊天或终端会话中，团队其他成员可能并不知道。
这就是项目管理开始超越简单任务列表的地方。
任务可以成为工作的共享记忆。
在 Sharkly 中，任务保存着目标、状态、负责人、评论、附件、活动记录和 Agent 执行信息。
这为人们和 Agent 提供了一个可以返回的地方。
面向 Agent 的项目管理工具究竟应该做什么？
我认为，这正是 面向 Agent 的项目管理工具 的定义开始与传统项目管理软件产生分歧的地方。
它不一定要完全替代像 Jira 那样的工具所做的一切。
但它需要理解，Agent 是能够实际执行工作的。
以下是我期望看到的一些能力。
1. 将工作分配给人类和 Agent
任务不应该默认执行者总是人类。
系统应该能够清晰地表示人类负责人和 Agent 执行者。
Sharkly 的任务模型支持将人员、Agent 和团队（Crew）分配为负责人。
2. 保留上下文
Agent 需要访问相关的任务信息，而不是每次只收到一个脱节的提示词。
这包括需求、评论、代码库、技能以及其他的执行配置信息。
3. 保持执行历史
如果 Agent 进行了更改，团队应该能够了解发生了什么。
Sharkly 将任务工作流状态与 Agent 运行状态分开，并维护诸如排队、运行中、已完成、已失败和已取消等执行状态信息。
4. 允许人类干预
Agent 不应该像黑箱一样运作。
人类应该能够添加上下文、回答问题、提供纠正、审查结果、停止运行、重试工作或重新分配任务。
Sharkly 的工作流支持后续评论、人类关注状态、取消、重试和重新分配。
5. 实现交接
启动任务的人不一定需要是完成任务的人。
而开始工作的 Agent 也可能不是处理下一个阶段的 Agent。
项目管理工具应该使这些转换可见，而不是将它们隐藏在私人对话中。
从单个 Agent 到 Agent 团队
当你不再考虑单个 Agent 时，下一步就变得更加有趣了。
想象一个软件项目，其中不同的 Agent 承担不同的职责。
一个 Agent 负责实现。
另一个专注于测试。
另一个处理文档。
另一个调查生产问题。
现在的问题是：
你如何协调它们全部？
Sharkly 使用 团队（Crew） 的概念来解决这个问题。
一个团队（Crew）将一个领导 Agent 与其他 Agent 和人员组合在一起，这样一项复杂的任务就可以被分配给一个可复用的团队，而不是单个执行者。
这开始看起来不像是“AI 自动补全”，而更像是一个具有专业能力的开发团队。
例如：
功能请求
↓
规划
↓
实现 Agent
↓
测试 Agent
↓
审查
↓
文档 Agent
↓
人类批准
人类不一定需要手动编排每一次转换。
重要的是工作保持关联。
Agent 不是项目经理
我认为另一个重要的区别是。
一个 AI Agent 执行一项任务，并不意味着该 Agent 应该成为整个项目的管理者。
人类仍然负责决定：
- 应该构建什么？
- 为什么要构建它？
- 哪些约束很重要？
- 应该优先考虑什么？
- 什么是可接受的？
- 工作何时准备好发布？
Agent 可以执行。
项目管理层可以协调。
人类可以做出重要决策。
这种分离实际上是我认为基于 Agent 的项目管理有意义的原因之一。
我们不是想让 AI 替代团队。
我们是想让团队能够与能力更强的 AI 系统协同工作。
一个人类 + Agent 的实际工作流
假设一个团队想为其应用程序添加一种新的支付方式。
以下是我设想的工作流如何运作。
1. 创建需求
一位开发人员创建一个任务，描述支付集成及其验收标准。
2. 分配实现任务
实现任务被分配给合适的编码 Agent。
3. Agent 调查
Agent 检查代码库，并确定现有的支付架构是如何工作的。
4. Agent 实现
它进行所需的更改并运行相关测试。
5. 开发人员干预
开发人员注意到实现没有考虑到一个现有的移动端工作流程。
他们将该信息添加到任务中。
6. Agent 调整
Agent 收到后续的上下文并继续工作。
7. QA 审查
另一个人检查实现情况，并要求增加测试覆盖率。
8. Agent 处理后续
Agent 根据新的需求运行另一次执行。
9. 人类批准
一位开发人员审查最终结果，并决定是否准备好合并。
注意发生了什么。
没有一个巨大的单一提示词。
没有一个完全自主的 AI 流程。
也没有人在工具之间手动复制每一段上下文。
相反，工作通过一个共享的任务进行流转。
这是我发现最有趣的模式。
把 Agent 的工作变成团队的工作
一旦 AI Agent 开始处理真实的开发任务，讨论的范畴就不再局限于 Agent 本身了。
你需要一个地方来保存需求、相关上下文、对话、执行历史以及最终的结果。否则，这些工作很容易就会被绑定在某个人的终端或某个私有的 AI 会话中。
这正是 Sharkly.ai 采取了一种有趣方法的地方。
它不是将 Agent 会话视为一切的核心，而是以任务作为围绕工作的共享工作区。人们可以贡献上下文和决策，而指定的 Agent 则负责执行。
工作流的不同部分扮演着各自的角色。Agent 定义了某类工作应如何被处理。Computer 提供了该工作可以运行的环境。Runtime 处理实际的执行。然后，任务将这项工作带回到一个共享的上下文中，团队其他成员可以跟进。
这种分离是有用的，因为 Agent 不必为每个任务从头开始重建。
一个团队可能有一个配置为负责后端开发的 Agent，另一个负责测试，还有一个负责文档。每个 Agent 都可以有自己的指令、技能、代码库、环境和运行时配置，而各个任务则提供了需要完成工作的具体需求和上下文。
这就创造了一种不同于以往每当有工作要做时就打开另一个 AI 聊天的工作流程。
Agent 变成了一种可复用的能力。
任务则成为具体的工作项。
团队中的成员依然是流程的一部分。
对于尝试使用多个 Agent 的团队来说，这种区分变得越来越重要。挑战不仅仅在于让一个 Agent 完成一个任务，更在于确保它所完成的工作能够被团队其他成员理解、审查、重新导向并继续推进。
当 Agent 卡住时怎么办？
这是人与 Agent 协作的另一个重要环节。
Agent 仍然会遇到卡壳的情况。
它们可能遇到失败的测试、缺失的凭证、不明确的需求、依赖问题，或者需要人类决策的情况。
一个有用的系统不应将这些情况隐藏起来。
它应该将需要人类关注的地方显现出来。
在 Sharkly 中，Agent 可以让一个任务等待人类的回复或审查。失败或受阻的工作也可以作为待办事项出现在收件箱中，相关负责人可以打开任务、进行回复、审查结果、重试，或者决定是否重新分配这项工作。
这是工作流中重要的一环。
自主性并不意味着人类消失。
它意味着人类将注意力投入到真正需要的地方。
从 AI 助手到 AI 队友
我认为我们正接近一个转折点，将每个 AI 开发工具都称为“助手”已经变得不那么准确了。
助手传统上是等待你指示的。
而 Agent 可以负责执行一项被明确定义的工作。
这创造了一种完全不同的协作模型。
团队最终可能拥有：
人类开发者
AI 编码 Agent
测试 Agent
研究 Agent
文档 Agent
运维 Agent
而所有这些都可能为同一个产品做出贡献。
困难的部分并不一定在于找到一个能够编写代码的 Agent。
已经有许多能力出色的选择。
困难的部分将在于协调所有这些工作。
谁分配了这个任务？
Agent 收到了什么上下文？
它修改了什么？
执行过程中发生了什么？
下一个参与者需要知道什么？
什么内容需要审查？
接下来应该做什么？
这些都是项目管理的问题。
结语
关于 AI Agent，一个有趣的问题不仅仅是它们是否能编写更多代码。
而是我们的开发工作流是否已经准备好让它们成为工作中的真正参与者。
如果一个 Agent 可以调查问题、修改代码库、运行测试，并在多个步骤中持续工作，那么仅仅将它视为一个简单的聊天机器人就显得过于局限了。
更好的模式是协作。
一个人定义目标。
一个 Agent 执行。
另一个人补充上下文。
Agent 进行调整。
审查者检查结果。
另一个 Agent 可以接手下一个阶段。
而团队则始终连接在整个流程中。
这就是为什么我认为面向 Agent 的项目管理将成为一个独立且重要的领域。
目标不是将人类从软件开发中移除。
而是创建一种工作流程，让人类和 Agent 可以在同一个问题上协同工作，而不会在每次责任交接时丢失上下文。
AI 现在可以完成更多的工作。
接下来的挑战是弄清楚当它在工作时，我们如何一起工作。
原文：https://dev.to/therealmrmumba/how-humans-and-ai-agents-can-work-together-a-practical-guide-to-agent-based-project-management-36p6（作者 @therealmrmumba）
