Chuck

Larkway - feishu 版 claude tag
Turn your Claude Code / Codex subscription into a Feishu agent your whole team can @

[Chuck @chuck686]

@FiniYang “第一公民”这个说法很准。研发协作里的 agent 如果只是某个人电脑里的助手，很难成为团队资产；但如果它有稳定入口、受控权限、可换模型底座、能读真实工程上下文，并把执行过程回到团队线程里，很多重复答疑和标准流程才有机会被接管。

[Chuck @chuck686]

@GoSailGlobal @Mention 会，但我觉得第一步不一定是买一整套企业版协作 agent。更稳的是先挑 2-3 个低风险、高重复的流程：查模块行为、整理 issue 背景、跑固定脚本、生成验收证据。团队先习惯在原来的 IM 里 @ 它拿结果，再慢慢放大权限。

[Chuck @chuck686]

@wey_gu 这里我也更关心 credential、scope 和审计，而不是“给 AI 起个人名”。Claude Tag 这条路线很完整，但门槛也会让不少团队只能围观。更轻的做法可能是：先把飞书这类已有 IM 当入口，后面接一个受控的本地执行环境，模型底座可换，权限和证据链先跑通。

[Chuck @chuck686]

@laobaishare 我觉得“不下班同事”只是表层，更大的变化是少掉重复解释。很多团队问题本来就在聊天线程里发生：这个 bug 怎么查、这个接口谁改过、这个流程跑到哪了。比起再开一个 AI 窗口，更自然的是在原来的 IM 里 @ 一下，让 agent 去真实上下文里执行，再把结果交回来。

[Chuck @chuck686]

@FinanceYF5 第三阶段如果成立，应该不是某个单一模型的专属形态，而是“LLM 出现在工作原地”。工程团队里，代码、日志、脚本、PR、讨论都散在不同地方；如果团队能在飞书/Slack 里 @ 起一个可换底座的执行 agent，让它去真实环境干活再回写证据，这个交互成本会低很多。

[Chuck @chuck686]

@FinanceYF5 评论里有人问和各种 IM agent 有什么区别，我理解差异不在“接进哪个聊天软件”，而在能不能形成一套可信工作闭环：谁触发、能看什么、用哪个模型/工具、在哪里执行、结果怎么被团队继续追问。底座模型最好别锁死，入口也最好贴着团队原来的协作工具。

[Chuck @chuck686]

@oran_ge channel based context 的启发点是：agent 的边界可以来自工作现场，而不是来自某个模型或某套企业版产品。飞书、企微、钉钉这类 IM 其实也有机会做出类似形态，差别在于后面有没有稳定的执行面：能读真实上下文、能跑工具、能把过程和结果回到原线程里。

[Chuck @chuck686]

@dotey @Claude 看前排几个问题，我觉得关键不只是“能不能把 bot 放进群”，这个很多团队已经在试了。更难的是把入口、权限、执行环境、预算/订阅、结果回写和审计拆清楚。国内团队未必非要等 Slack Enterprise 这一路线，先在飞书里把 @ 入口 + 本地执行 + 可追溯回写跑通，可能更接近真实落地。

[Chuck @chuck686]

@sitinme 第 5 点很关键：不可逆动作一定要人确认。比较稳的形态是 agent 先按 SOP 做可验证的前置工作，比如查代码、跑脚本、整理证据、开 draft，再把结果回到群里让人拍板。这样既有自动化，也不会把责任边界弄糊。

[Chuck @chuck686]

@canghe @Claude 我觉得“同事感”成立的关键，不只是常驻 Slack，而是它能接触真实工作上下文。对工程团队来说，能不能读代码、跑测试、看日志，再把过程和结果回到频道里，比单纯问答更关键。中文团队如果主工作流在飞书，这个形态也很自然。

[Chuck @chuck686]

@9hills 这个问题我也在看。多人群聊里最容易乱的不是“能不能 @ agent”，而是三件事：谁能让它看什么、它在哪里真正执行、结果怎么回到同一个 thread 里让人接着验收。我们在飞书场景里试的思路是：群聊只做入口和审计，本地 agent 去读 repo/跑命令，完成后把证据和结论写回来。

[Chuck @chuck686]

Larkway 飞书版 Claude Tag ~

[Andrej Karpathy @karpathy]

This is a new paradigm for interacting with Claude that is significantly more "inline" with all the other human activity org-wide. Once you do all of the under the hood engineering work to make this "just work" (e.g. across tools, integrations, compute environments, memory, security, etc.), Claude basically joins the team in a seamless way - you can talk to it as you would talk to a person and it can help with a very large variety of workloads.

Imo this is the 3rd major redesign of LLM UIUX. The first paradigm was that the LLM is a website you go to, the second was that it is an app you download to your computer. This third one is that it is a self-contained, persistent, asynchronous entity with org-wide tools and context, working alongside teams of humans. It really takes a while to wrap your head around it, but it works and it is awesome.

[Chuck @chuck686]

@ekcheungAI The strongest part is that the workflow starts from a real human run. Some recurring work is too preference-heavy to describe from scratch, but easy to standardize after one good walkthrough.

[Chuck @chuck686]

@yuhasbeentaken This framing is useful. I’d add an explicit stop condition as a first-class part of the loop; otherwise the system can keep spending tokens after the useful work is done.

[Chuck @chuck686]

@jasonzhou1993 The shared artifact + verification layer feels like the part most people skip. Without those, a loop is just a prompt that gets more expensive every time it drifts.

[Chuck @chuck686]

A useful loop is not a long prompt that keeps running.

It starts as a workflow a human already ran once.

Then make the hidden parts explicit: inputs, stable steps, state, verification, and stop conditions.

That is the difference between automation and a loop you can trust.

[Chuck @chuck686]

@i5ting Agree on being skeptical of benchmarks. The useful question is whether the system gives teams a clearer spec, isolated execution, and a review gate in real projects.

[Chuck @chuck686]

@cline The interesting bit here is not just cost. It is that the run spent effort verifying the build and cleaning dead code. That feels closer to the behavior teams actually need from coding agents.

[Chuck @chuck686]

@AdrianPunk115 This is the part most teams skip. The agent can be smart, but if source, time, authority, and risk checks are not part of the workflow, humans still become the QA layer every time.

[Chuck @chuck686]

Agent loops are not about letting the model run forever.

The useful loop is:
1. get the task
2. read the real context
3. do the work
4. verify it
5. write back what changed

For team workflows, the unlock is boring:
make verification the default, not a reminder.